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PREFACE 

The  technology  described  in  this  guidebook  is  part  of  a  broad  approach  to  software  productivity 
improvement.  This  preface  provides  an  overview  of  that  approach  and  identifies  the  series  of  guide¬ 
books  that  support  it.  These  guidebooks  were  developed  by  the  Software  Productivity  Consortium  un¬ 
der  contract  to  the  Virginia  Center  of  Excellence  for  Software  Reuse  and  Tbc^ology  Ttansfer 
(VCOE).  For  a  complete  listing  of  VCOE  guidebooks  and  products,  call  the  Software  Productivity 
Consortium’s  Tfechnology 'Ransfer  Clearinghouse  at  (703)  742-7211. 

Each  technology  has  been  packaged  so  it  can  be  used  without  reference  to  the  other  technologies. 
However,  it  is  also  possible  to  combine  these  technologies  into  an  integrated  approach  for  product 
development.  Figure  P-1  shows  how  the  guidebooks  for  these  technologies  relate  to  the  practices  of 
software  development  organizations. 


Drivers  and  li«nds  System  Contracts 

Figure  P-1.  Structure  for  Integrated  ^>pIication  of  Consortium  Tedinologies 

These  practices  are  composed  of: 

•  Improvement  Efforts  (IE).  Application  of  technology  to  improve  software  development  efforts. 
These  efforts  require  managed  approaches  to  assessment  of  objectives  and  current  ca¬ 
pabilities,  planning  for  the  improvement,  implementation  of  the  plan,  and  measurement  of 
success. 

•  Development  Efforts.  Development  of  products  that  meet  the  needs  of  customers  and  markets 
or  products  that  make  the  organization  more  competitive  in  meeting  expected  future  needs. 
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—  Organiz0ional  Process  Development  (OPD).  Development  of  standardized 
organizational  process  assets  (e.g.,  process  and  method  descriptions,  process 
enactment  tools)  tailored  for  a  particular  organization. 

—  Product-Line-Based  Product  and  Process  Devdopment  (PLD).  Developnicnt  of 
integrated  product  and  process  assets  (e.g.,  core  products  and  processes  for  adapting 
them  for  particular  customer  needs)  appropriate  for  a  particular  product  line. 

-  Project  ^plication  Devdopment  (PAD).  The  tailoring  and  application  of  organizational 
assets  for  a  particular  product  development  effort. 

Ikble  P-1  describes  how  existing  products  can  be  integrated  to  address  your  organizational  practice. 

Ikble  P-1.  Consortium  Guidebooks  and  Related  Practices 


Guidebook 

Part  Number 

Relationship  to  Software  Practice 

Consortium  Requirements 
Engineering  Guidebook 

SPC-92060-CMC 

Used  for  defining  and  analyzing  requirements 
in  PAD.  Adaptable  for  use  in  PLD. 

Managing  Process 
Improvement:  A  Guidebook 
for  Implementing  Change 

SPC-93105-CMC 

Supports  EB  by  providing  a  process  and 
sup^rting  guidance  for  initiating  and 
maintaining  an  organizational  process 
improvement  program. 

Process  Definition  and 
Modeling  Guidebook 

SPC-92041-CMC 

Provides  methods  for  defining  and 
documenting  processes  so  they  can  be 
analyzed,  modified,  and  enacted.  Supports  IE 
and  OPD. 

Process  Engineering  With  the 
Evolutionary  Spiral  Process 
Modd 

SPC-93098-CMC 

Used  to  iteratively  plan,  manage,  and  control 
PAD  and  PLD.  Us^  to  construct 
organization-specific  processes  in  PLD  and 
tailor  them  in  PAD. 

Reuse  Adoption  Guidebook 

SPC-92051-CMC 

Supports  EE  by  providing  specific  process 
improvement  activities  for  incorporating  reuse 
practices. 

Reuse-Driven  Software 
Processes  Guidebook 

SPC-92019-CMC 

Provides  development  approaches  for  PLD 
(domain  engineering)  and  PAD  (application 
engineering)  of  reusable  software  assets. 

Software  Measurement 
Guidebook 

SPC-91060-CMC 

Supports  IE  by  providing  methods  for 
quantitative  assessment  of  project  status. 

Using  New  Technolt^ies:  A 
Technology  Hanger 
Guidebook 

SPC-92046-CMC 

Supports  IE  by  providing  a  process  that 
addresses  how  to  get  an  organization  to  use 
new  technologies. 
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1.  INTRODUCTION  TO  PROCESS  IMPROVEMENT 


A  competitive  world  has  two  possibilities  for  you.  You  can  lose.  Or,  if  you  want  to  win,  you  can  diange. 

Lester  C.  Thurow,  Dean,  MIT  Sloan  School  of  Management 


Section  Objectives 

1.  Explain  wl^you 
should  u^  tins  guidebook 

2  Describe  how  to  use 
tins  guidebook 


This  guidebook  guides  you  through  imtiadng  and  maintaining  a  process 
improvement  program  in  your  (vganizatum.  Sped&alfy,  Uus  guukbodc 
you  to: 

•  Understand  and  implement  the  steps  to  improve  your  software 
process 

•  Gain  broad  support  for  and  manage  the  human  challenges  of  major 
change,  such  as  process  improvement 

•  Successfully  initiate  and  sustain  a  process  improvement  program 
The  primary  audience  for  this  guidebook  includes: 

•  Persons  advocating  process  improvement 

•  Persons  implementing  process  improvement 

The  secondary  audiences  includes  persons  who  control  resources  for 
process  improvement  and  persons  affected  by  process  improvement. 
Whether  you  are  at  the  beginning  or  already  have  a  process  improvement 
effort  underway  (or  even  if  you  are  trying  to  reinvigorate  a  stalled  one), 
this  guidebook  can  help  you. 

A  software  process  is  a  set  of  activities  that  people  perform  to  develop  and 
maintain  software  and  associated  products  (e.g.,  project  plans,  design  doc¬ 
uments,  code,  test  cases,  user  manuals,  etc.).  Hie  people,  process,  and 
technologies  used  to  implement  the  process  are  interdependent  and  affea 
successful  cost,  schedule,  and  quality  performance. 

The  remainder  of  this  section  provides  reasons  vtliy  you  should  initiate  a 
process  improvement  program  in  your  organization  and  explains  how  to 
use  this  guidebook. 


LI  SOFTWARE  PROCESS  IMPROVEMENT  WHY  IT  IS  ESSENTIAL 

Recent  estimates  by  IDC  Software  Researdi  (Brandt,  Sdiwartz,  and  Gross 
1991)  indicate  that  the  U.S.  currently  controls  about  57%  of  the  global 
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software  market,  the  total  value  of  wdiidi  is  estimated  to  be  as  hi^  as  $58 
billion,  making  it  one  of  our  nation’s  most  valued-^and  threatened — areas 
of  technological  superioriQr. 

The  U.S.  software  industry  is  being  diallenged  from  many  directions: 
European  firms  are  increasingly  refusing  to  buy  or  receive  bids  from 
suppliers  whose  quality  systems  do  not  comply  with  International  Stan¬ 
dards  Organization  (I^)  9000  standards;  India’s  software  market  grew 
47%  to  $112  million  in  1992,  while  exports  of  software  packages  rose  to 
$144  million  (l^argava  1993);  software  development  costs  in  the  United 
States  are  five  to  six  times  more  than  those  of  Singapore  (Yourdon  1992). 
As  time  passes,  the  «dstence  of  a  systematic  software  process 
improvement  program  is  moving  from  an  option  to  a  necessity— part  of  the 
cost  of  doing  business  or,  more  positively,  essential  to  your 
competitiveness. 

The  message  is  clear:  The  U.S.  software  industry  must  increase  its 
competitiveness  to  maintain  and  expand  its  dominance  in  the  worldwide 
arena. 

1,2  WHY  THIS  GUIDEBOOK  CAN  HELP  YOU 

This  section  discusses  the  experiences  and  lessons  learned  on  v4)idi  this 
guidebook  is  based.  Expected  benefits  from  improving  your  process  are 
enumerated. 


This  Guidebook  Incorporates  the  Lessons  of  Experience 

This  guidebook  incorporates  material  that  is  the  result  of  many  years  of 
industrial  experience,  both  in  general  and  for  software  in  particular.  The 
principles  behind  the  software  quality  movement  are  based  on  a  similar 
movement  in  the  manufacturing  industry  that  occurred  over  several 
decades. 

In  1920,  after  the  introduction  of  the  assembly  line,  product  inspection  was 
the  way  to  control  quali^,  sometimes  referred  to  as  ’’inspecting  in  quality.” 
Around  1960,  Japan  began  a  major  effort  to  penetrate  the  global  electron¬ 
ics  market  and  adopted  statistical  process  control  methods  to  improve 
quality  in  manufacturing.  Japan’s  success  has  driven  most  manufacturers 
to  adopt  similar  techniques.  In  the  1980s,  attention  shifted  to  improving 
the  underlying  process  and  product  designs  to  achieve  quality  control  and 
improvement,  sometimes  referred  to  as  “building  in  quality.”  This  shift  of 
emphasis  from  a  product-centered  to  a  process-centered  approadi  to 
qualk  /  has  not  been  easy  or  quick. 
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Process  management  fn^ovides  a  systematic  approach  to  [danning, 
managing,  and  imf^roving  quality.  Shewart  intrt^uced  a  continuous 
process  improvement  (^le,  called  Plan-Do-Check-Act  (Deming  1982). 
Juran  (1981)  defined  a  four-step  approadi  to  quality  imfvovement. 
Deming  (1982)  proposed  a  14-point,  organization-wide  approach  to 
quality  management.  Crosby  (1979)  developed  a  quality  management 
maturity  framework  to  identify  where  an  organization  stands  from  a 
quality  viewpoint.  Incorporating  these  ideas  and  approaches,  the  Software 
Engineering  Institute  (SEI),  funded  by  the  De|»rtment  of  Defense, 
developed  a  conceptual  framework,  the  Capability  Maturity  Model  for 
Software  (CMM),  that  provides  an  evolutionary  path  for  improving  the 
way  you  manage  software  activities. 

The  key  message  from  these  and  other  leaders  in  the  quality  movement  is 
that  long-term  improvement  can  be  attained  only  from  systematic  analysis 
and  actions,  not  simply  by  exhortations  or  management  by  objectives 
(Paulk  et  al.  1993,  ^p.  B). 

The  Software  Productivity  Consortium  has  been  involved  in  helping  many 
organizations  in  industry  improve  their  software  process  and  is  an  autho¬ 
rized  vendor  for  the  SEI  Software  Process  Assessment.  This  guidebook 
outlines  a  systematic  process  for  you  to  follow  in  order  to  initiate  and  sus¬ 
tain  a  process  improvement  program  in  your  organization.  This  guidebook 
is  based  on  research,  experiences,  and  lessons  learned  from  improving 
processes.  Tkke  advantage  of  its  hard-won  lessons  on  how  to  improve  your 
process  using  successful  approaches  and  with  knowledge  of  where  the  pit- 
falls  are,  so  that  you  can  duck  the  same  arrows  that  pioneers  have  already 
suffered. 


Potential  Beneftts  are  Numerous 

When  improving  and  defining  your  process,  your  organization  can  expet^ 

to  experience  some  of  the  following  benefits: 

•  Decreased  Rdiance  on  Testing  to  Ensure  Quality.  Reviews  become  an 
integral  part  of  the  process — ^throughout  the  life  cycle. 

•  Improved  Teamwork.  Communication  among  the  prcx^ess  usei:, 
managers,  process  developers,  and  customers  is  more  effective. 

•  Seduced  Sework.  You  identify  and  eliminate  problems  early  in  the 
process  rather  than  later. 

•  Eifficiaa  Prcyec:  Ste^ Start-Up  Time.  There  is  a  documented  process  on 
which  to  train  them. 

•  Seduced  Development  Costs.  You  develop  less  and  reuse  more. 
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•  Improved  PredictabUity  of  Budgets  and  Schedules.  You  stabilize 
development  activities  and,  therefore,  know  what  to  measure,  u^en  to 
measure  it,  and  how  to  use  the  information. 

•  Improved  Tool  Usage.  The  right  tools  can  be  selected  the  first  time  to  fit 
the  process  you  know  you  will  use. 

•  Faster  Project  Start-Up.  The  project  can  build  on  and  tailor  a 
documented  history  of  what  it  has  done  in  the  past. 

L3  HOW  TO  USE  THIS  GUIDEBOOK 

This  section  tells  you  the  content  of  eadi  section  of  this  guidebook  and 
whether  it  is  relevant  to  you.  Related  guidebooks  and  their  purposes  are 
described. 


Guidebook  Contents 


This  guidebook  is  organized  as  follows: 

•  Section  1,  Introduction  to  Process  Improvement,  provides  a  compelling 
argument  for  initiating  a  i^ocess  improvement  ivogram. 

•  Section  2,  Why  Process  Improvement  is  Difficult,  identifies  the  key 
challenges  you  will  face  and  explains  how  to  apply  change  management 
prindples  to  address  them. 

•  Section  3,  How  Do  You  Use  the  Process  Improvement  Process?, 
explains  the  fundamentals  of  using  this  process  and  introduces  the 
format  of  Sections  4  through  8. 

•  Section  4,  Establish  a  Baseline;  Understand  Context,  helps  you  to 
understand  your  organizational  and  technical  environment,  and  to 
define  objectives  and  alternatives  for  how  to  proceed. 

•  Section  5,  Look  Before  You  Leap;  Analyze  Risks  and  Select  Strategy, 
helps  you  to  analyze  and  resolve  the  risks  associated  with  the  process 
improvement  program,  and  to  select  the  most  appropriate  strategy  for 
your  organization. 

•  Section  6,  Chart  a  Course;  Plan  Improvements,  helps  you  to  plan  the 
next  step  of  your  process  improvement  implementation. 

•  Section  7,  Just  Do  It:  Implement  Improvements,  helps  you  to 
implement  and  manage  process  improvements,  as  defin^  1^  your 
action  plan. 
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•  Section  8,  Steer  for  SiKxess:  Review  and  Update,  helps  you  to  interpret 
the  results  of  the  program  to  date  and  provides  guidance  on  how  to 
proceed,  based  on  these  results. 

•  Section  9,  Imfvoving  Your  Process  Improvement  Process,  provides 
guidance  for  becoming  more  proactive  in  supporting  your  process 
improvement  program. 

Appendix  A,  Ch^klists  for  i^>plying  the  Process  Improvement 
Process,  provides  three  checklists  for  guiding  the  implementation  of 
process  imftfovement  tasks. 

i^)pendix  B.  Software  Process  Assessment  Methods,  provides  an 
overview  of  three  popular  software  process  assessment  methods. 

Appendix  C,  Assessment  Findings  Presentation  Outline,  provides  an 
outline  for  an  assessment  findings  presentation. 

Appendix  D,  Hndings  and  Recommendations  Report  Tbmplate, 
provides  a  template  for  a  findings  and  recommendations  report 

Appendix  E,  Assessment  Recommendations  Presentation  Outline, 
provides  an  outline  for  a  recommendations  presentation. 

Appendix  F,  Risk  Management  Plan  Tbmplate,  provides  a  temfdate 
for  a  risk  management  plan. 

Appendix  G,  Action  Plan  Tbmplate,  provides  a  template  for  an  action 
plan. 

Appendix  H,  Measuring  Process  Improvement  provides  an  overview 
of  process  and  product  measurements  that  are  useful  for  measuring 
improvements. 


WmcH  Sections  are  for  You 

Tb  help  you  decide  v^ch  sections  you  should  read,  see  TU)le  1-1,  vdiidi 
identifies  the  audience  types  and  the  sections  of  this  guidebook  that  eadi 
should  read.  Keep  in  mind  that  at  any  one  time,  you  may  fit  the  descripticn 
of  more  than  one  audience  ^pe;  for  example,  you  may  control  resources 
as  well  as  be  affected  by  process  improvement  efforts. 


1.  iBtrodaction  to  ProcMi  Improwement 


TaUel'l.  Guittebook  Audience 
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Relahonship  of  Process  Improvement  to  Titciinology  Transfer 

The  related  processes  of  process  improvement  and  tedmology  transfer 
have  the  same  high-level  goal:  to  improve  your  organization’s  practices  by 
changing  the  way  the  staff  works.  What  differs  is  the  focus  and  scope — pro¬ 
cess  improvement  is  concerned  with  the  improvement  of  an  entireprocess, 
whereas  tec^ology  transfer  (sometimes  referred  to  as  technology  transi¬ 
tion)  is  concerned  with  the  improvement  of  a  certain  technical  area 
through  the  use  of  a  new  tedmology. 

lb  implement  and  support  these  related  processes,  this  guidebook  and  the 
guidebook  U^g  New  Technologies:  A  Technology  Thinker  Guidebook 
(Software  Froductivi^  Consortium  1993e)  are  integrated.  Specifically,  the 
integration  of  the  process  improvement  process  and  the  tedmolt^ 
transfer  process  follows  these  guidelines: 

i 

i 

•  Similar  Processes,  Since  the  high-level  goals  of  the  process 
improvement  process  and  tedmology  transfer  are  similar,  the 
processes,  including  the  activities  and  ordering  of  the  activities,  is 
similar. 

•  Similar  Guidance,  Each  provides  guidance  that  applies  to  both 
processes  as  well  as  guidance  that  is  spedfic  to  its  own  process;  this 
latter  guidance  is  what  makes  each  guidebook  unique  to  the  problem 
that  you  are  solving. 

•  Similar  Appearance,  The  two  guidebooks  intentionally  have  been 
formatted  similarly,  so  that,  if  necessary,  you  can  easily  refer  to  one 
guidebook  firom  the  other. 
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This  guidebook  refers  you  to  f/jzng  New  Ticfuioiogies  at  the  apprqidate 
points  during  the  process  improvement  process. 


Other  Related  Guidebooks 

Several  other  guidebooks  provided  by  the  Consortium  may  also  be  of 
interest  to  you.  Persons  wishing  more  information  on  defining  and 
modeling  their  process  can  refer  to  Process  DefinMon  and  Modeling 
Guidebook  (Software  Productivity  Consortium  1992a).  For  more  on 
process  engineering,  refer  to  Process  Eng^i^ring  With  the  Evolutionary 
Spiral  Process  Model  (Software  Productivity  Consortium  1993b).  For 
improving  software  reuse,  refer  to  Reuse  Adcqaion  Guidebook  (Software 
Productivity  Consortium  1993c). 

Additional  materials  include  the  Software  Measurement  Guidebook 
(Software  Productivity  Consortium  1992b),  Reuse-Driven  Software  Process 
Guidebook  (Software  Productivity  Consortium  1993d),  and  Cmsortium 
Requirements  Engineering  Meth^  Guidebook  (Software  Productivity 
Consortium  1993a),  all  from  the  Wginia  Center  of  Excellence  in  Software 
Reuse  and  Ifectmology  Itansfer. 


1.  iBtroduciion  to  Procew  Improwmcol 


This  page  intentionalfy  left  blank. 
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2.  WHY  PROCESS  IMPROVEMENT  IS  DIFFICULT 


We  have  met  the  enemy,  and  he  is  us. 

Wilt  Kelly,  Creator  of  Pogo  (comic  strip  diaracter) 

You  are  reading  this  guidebook  because  your  organization  needs  to: 

•  Decrease  the  time  it  takes  to  develop  software 

•  Decrease  the  cost  of  producing  software 

•  Inaease  the  quality  of  your  software  products 

•  Increase  the  predictabiliQr  of  your  performance 

•  Increase  your  capacity  to  produce  wealth  (i.e.,  capability  and  market) 

lb  achieve  these  objectives,  you  must  first  understand  why  achieving 
substantial  improvement  is  not  a  simple,  straightforward  problem  to  solve. 
This  section  discusses  the  many  facets  of  your  organization  and  the 
fundamental  concepts  underlying  organizational  change. 

2.1  YOUR  ORGANIZATION  IS  A  COMPLEX  SYSTEM 

Consider  your  organization  as  a  set  of  interrelated  subtystems  operating 
in  an  organizational  environment,  as  depicted  in  Figure  2-2  (Morgan 
1986).  For  your  organizaticm  to  be  eCBdent,  you  need  to  analyze  and 
improve  each  of  these  subsystems: 

•  Strat^.  Does  your  organization  have  a  business  strategy,  or  does  it 
simply  react  to  whatever  changes  come  along? 

•  TKhnoloffcal,  Are  the  processes  that  transform  inputs  into  outputs 
standardized  and  institutionalized?  Do  the  processes  rigidity 
operations,  or  are  they  flexible?  What  types  of  technologies  are  being 
used? 

•  HumanICultural.  What  are  the  core  values,  behaviors,  and  unwritten 
rules  that  shape  your  organization’s  culture?  What  orientations  do 
people  bring  to  work?  Are  they  searching  for  challenge  and 
involvement,  or  simply  working  for  money? 


Section  Objectives 

1.  Discuss  the  crnnpieidty 
cf your  orgcuuzation 

2.  ExpUdn  change 
management  principles 
and  why  they  are  critical 
to  your  change  efforts 
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Organizatknal 


•  Structural.  Is  your  organization  bureaucratic,  hierarchical,  or  matrix  in 
structure?  Are  Integrated  Product  Ibams  (IPTS)  used? 


•  Managerial.  Does  the  dominant  managerial  philosophy  stress 
accountability  and  control  (authoritarian),  or  encourt^e  mitiative  and 
enterprise  (democratic)?  Does  the  organization  stress  innovation  and 
risk  taking? 

It  is  interesting  to  note  that  all  but  the  managerial  and  human/cultural 
subsystems  can  be  duplicated  by  your  competition.  Most  of  this  guidebook 
focuses  on  improving  the  technological  and  managerial  subsystems  of  your 
organization.  Since  these  five  subsystems  are  interrelated,  this  guidebook 
also  addresses  the  other  subsystems,  thus  presenting  a  more  integrated 
approach  to  process  improvement 

2.2  HUMAN  ASPECTS  OF  CHANGE  ARE  THE  MOST  CHALLENGING 

The  most  important  asset  to  your  organization  is  its  people.  The  people 
who  are  involved  with  and  affected  by  change  are  considered  the  stake¬ 
holders  of  the  change.  History  has  demonstrated  that  major  changes,  such 
as  process  improvement,  are  likely  to  fail  when  the  stakeholders  are 
unprepared  for  its  implementation. 

This  guidebook  addresses  both  the  human  as  well  as  the  technical 
challenges  in  implementing  process  improvement  so  that  you  can  ino-ease 
the  likelihood  of  successful  implementation.  Tb  provide  a  solid  foundation 
for  you  to  best  understand  and  apply  this  guidance,  this  section  covers  the 
following  topics: 
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•  Imi^ementation  dimate  within  your  organization 

•  Readiness  of  your  organization  for  change 

•  Process  of  change 

•  Potential  responses  to  diange 


Implementation  Climate 

The  atmosphere  of  an  organization  can  greatly  impact  the  success  of 
process  improvements.  One  way  to  get  a  reading  of  the  atmosphere,  or 
climate,  is  by  looking  at  the  organization’s  history  of  change  and  the  stress 
of  individuds  within  the  organization  (Implementation  Management 
Assodates  1992). 

A  history  of  process  improvement  efforts  that  is  perceived  as  unsuccessful 
produces  an  unfavorable  climate  for  future  changes.  Employees  question 
what  will  be  different  this  time  around.  Managers  question  Ae  motives  of 
their  managers.  We  continually  hear  statements  such  as,  “We’ve  been 
down  this  road  so  many  times  that  we’ve  worn  out  the  pavement”;  “same 
song,  different  verse”;  “the  more  things  change,  the  more  they  stay  the 
same”;  and  so  on. 

Stress  also  affects  the  organization’s  abUity  to  implement  process 
improvements.  Organizations  that  add  one  more  activity  to  the  already 
overloaded  schedules  of  their  staff,  are  likely  to  suffer  the  consequences 
of  dysfunctional  behavior.  Eadi  activity,  taken  in  isolation,  is  doable,  but, 
when  taken  collectively,  may  possibly  exceed  your  staff’s  stress  limits. 
Process  improvements  do  not  occur  in  isolation,  but  it  is  very  difficult  to 
achieve  success  when  there  are  four  number-one  priorities  causing 
excessive  stress  on  the  organization  and  its  individuals. 

This  guidebook  shows  you  how  to  integrate  process  improvement  with 
other  thrusts,  such  as  T^tal  Quality  Management  (TQM),  and  to  minimize 
the  potential  of  overloading  your  organization. 


Organizational  Readiness 

An  organization  is  more  apt  to  be  successful  when  change  is  compatible 
with  the  culture  of  the  organization.  When  the  change  is  incompatible  with 
the  culture,  culture  always  prevails.  The  level  of  cultural  fit  with  the  change 
greatly  affects  stakeholder  readiness  and  acceptance  of  the  change,  and, 
thus,  the  probability  of  success. 
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2.  Why  Process  Improvement  Is  Diflicult 


Change  has  the  greatest  chance  of  success  when  your  organization  is 
unified  in  its  purpose  and  direction,  and  has  a  culture  that  supports  change. 
Figure  2-3  depicts  several  scenarios  of  organizational  readiness,  of  which 
only  one  is  really  conducive  to  change  (Perkins  1991). 


Unified  organization 

Organizational  chaos 

Thg-of-war 

Full-scale  war 

Figure  2-3.  Sceoaiios  of  Organizational  Readmess 


Change  is  a  Multi-Stage  Process 

The  one-stage  model  of  change,  sometimes  called  the  “hammer” 
approach,  usually  occurs  by  edict  or  mandate,  to  the  effect  of,  “Beginning 
today,  you  will  do  things  a  new  way.”  Compliance,  or  the  appearance  of 
compliance,  is  the  typical  result  of  the  hammer  approach. 

Experience  has  shown  that  successful  change  typically  occurs  in  three 
stages,  not  one.  The  three-stage  model,  shown  in  Figure  24,  illustrates  the 


Desired 


Unfreezing  Transition  Refreezing 


Figure  2-4.  Transition  Modd  of  Change 

need  to  communicate  the  why  and  how,  not  solely  the  desired  outcome. 
The  terms  used  to  describe  these  stages  can  be  found  in  Conner  (1993),  Im¬ 
plementation  Management  Associates  (1992),  and  Software  Engineering 
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Institute  (1992).  Similar  concepts  can  be  found  in  Kirkpatridc  (1985)  and 
Egan  (1988).  Tlie  stages  are  as  follows: 

•  Vitfremng.  In  this  stage,  the  need  for  change  is  stressed.  For  successful 
uidreezing,  the  cost  of  not  changing  (i.e.,  keeping  the  status  quo)  must 
exceed  the  cost  of  changing;  in  other  words,  an  organization  must  be 
in  pain.  This  stage  motivates  the  stakeholders,  based  on  a  vision  of  the 
new  way,  to  consider  changing  the  present  state. 

•  Transition.  This  stage  is  characterized  \sy  ambiguity,  fear  of  the 
unknown,  instability,  and  resistance,  and  involves  planning  and 
implementing  the  proposed  changes.  Clear  transition  steps,  with 
substantial  organizational  involvement,  are  required  to  counter  the 
uncertainty  inherent  in  transition.  If  this  stage  is  not  managed 
properly,  people  revert  to  “business  as  usual.** 

•  E^reezing.  This  stage  involves  the  ongoing  implementation  of  the 
proposed  changes  and  the  institutionalization  of  those  changes.  The 
productivity  and  morale  of  the  organization  rebounds  due  to  the 
visibility  and  realization  of  the  benefits  of  improvement,  thus 
achieving  the  desired  state. 

This  model  of  change  implementation  provides  a  framework  to 
understand,  manage,  and  accelerate  the  change  process.  The  guidance  in 
this  guidebook  helps  you  to  use  this  model  to  maximize  commitment, 
minimize  resistance,  and  increase  the  probability  of  implementation 
success.  Also,  this  guidebook  helps  you  to  phase  in  changes,  so  that  the 
entire  organization  never  drops  below  the  sustaining  level  of  productivity 
in  the  transition  stage. 


Human  Responses  to  Change  are  Complex 

Resistance  is  a  natural  response  to  change  that  causes  major  disruptions 
to  or  inconsistencies  in  the  status  quo.  The  more  dramatic  the  change  or 
its  perceived  consequences,  the  greater  the  resistance.  You  can  increase 
your  effectiveness  of  implementing  change  by  understanding  and 
respecting  this  response. 

People  express  their  resistance  differently.  Covert  resistance,  the  harder 
type  to  manage,  occurs  when  people  disagree  with  the  change  and  its  con¬ 
sequences,  but  do  not  voice  their  concerns.  Instead,  they  may  choose  to  un¬ 
dermine  or  sabotage  the  change.  Overt  resistance  is  much  easier  to 
manage;  people  articulate  their  concerns,  and  you  can  directly  address  the 
issues. 

People  respond  to  change  differently.  What  one  person  feels  is  a  positive 
change  may  be  seen  by  another  as  a  negative.  Some  people  resist  change 
even  if  the  change  is  perceived  to  be  positive. 
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The  typical  reaction  pattern  to  a  perceived  positive  change  is  depicted  in 
Figure  2-5.  The  terms  used  to  describe  th^  stages  are  found  in  OJD. 
Resources  (1989),  and  are  as  follows: 


Figute2*S.  Re^xxne  to  a  Pooeived  Positive  Qumge 

•  Stage  1,  Vninformed  Certainty.  In  this  stage,  a  person  is  confident  that 
the  change  is  entirely  for  the  better  and  has  high  expectations  for  the 
results. 

•  Stage  2,  Informed  Doubt.  In  this  stage,  a  person  begins  to  realize  that 
expectations  were  set  too  high.  Resistance  is  most  likely  to  surface 
during  this  stage  and  can  be  either  covert  or  overt. 

•  Stage  3,  Realistic  Concern.  In  this  stage,  a  person  begins  to  reconcile 
expectations  with  reality  and  to  think  positively  about  the  diange. 

•  Stage  4,  Iitformed  Certainty.  In  this  last  stage,  a  person  is  once  again 
confident  of  success,  but  only  because  of  a  better  understanding  of 
what  will  and  will  not  change. 

The  typical  reaction  pattern  to  a  perceived  negative  diange,  as  depicted  in 

Figure  2-6,  is  more  complex  and,  at  times,  subtle.  It  typically  follows  this 

pattern  (Kubler-Ross  1981): 

•  Stunned  Paralysis.  The  initial  reaction  to  a  perceived  negative  change 
is  one  of  stunned  paralysis.  The  change  is  so  foreign  to  an  individual’s 
frame  of  reference  that  it  causes  immobilization. 

•  Denial.  In  this  stage,  the  individual  denies  the  need  to  change. 
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Anger  and  rage 


Figure2^.  Response  to  a  Perceived  Negative  Change 

•  Anger  and  Kage.  Emotions  of  hurt  and  frustration  tend  to  surface 
during  this  stage. 

•  Bargaining.  This  stage  marks  the  beginning  of  acceptance  and  is 
characterized  by  the  individual  ne^tiating  around  Ae  diange  by 
requesting  exemptions  or  extensions. 

•  Depression.  When  bargaining  does  not  yield  the  desired  results,  the 
individual  begins  to  understand  the  full  octent  of  the  change  and  its 
consequences. 

•  Testify.  The  individual  begins  to  show  acceptance  of  the  change  by 
testing  its  boimdaries  and  limitations. 

•  Accq>tance.  The  individual  nowaccepts  thechange  and  its  implications. 
Acceptance  of  change  does  not  imply  that  the  individual  likes  the 
diange. 

Some  behaviors,  sudi  as  denial  and  depression,  maybe  difGcult  to  observe 
and  manage.  The  depression  phase  is  a  pivotal  point  vhen  an  individual 
is  ready  to  think  about  the  desired  state.  Without  proper  ‘‘care,*'  the  indi¬ 
vidual  may  slip  back  to  the  denial  stage  instead  of  moving  forward. 

This  guidebook  provides  insights  on  how  to  manage  both  types  of 
responses  to  change,  so  that  you  can  focus  on  the  desired  state  and  ai±ieve 
your  objectives  sooner. 


2.  WlyftoceMhnptovciBeatb  Difficult 


This  page  intaUionalfy  Ufi  blank. 
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3.  HOW  DO  YOU  USE  THE  PROCESS 
IMPROVEMENT  PROCESS? 


Give  a  man  a  fish  and  you  feed  him  for  a  day;  teach  him  how  to  fish  and  you  feed  him  for  a  lifetime. 

WeD-known  proverb 

Sec^n  Objectives  This  section  introduces  the  process  for  improvingyour  software  jvocesses, 

provides  suggestions  and  advice  on  using  the  process  successfully,  and  de- 

1.  Introduce  the  process  scribes  how  to  use  this  guidebook.  Read  this  section  before  you  proceed 

KithenmsMtion. 

2.  Eqtlain  how  to  use  this 
process 

3.1  A  PROCESS  IMPROVEMENT  PROCESS 

When  [banning  process  improvement,  it  is  natural  to  envision  imi^emaiting 
a  series  of  activities  performed  one  after  the  other.  The  {banner  is  tempted 
to  lay  out  a  sdieme  of  sudi  activities,  joined  arrows,  with  [banned  start  and 
finish  dates  for  eadi.  Unfortunately,  sucoes^  {v^ocess  improvement  never 
follows  such  a  predetermined,  static  jdan.  In  reality,  we  are  unable  to  predict, 
mudi  less  mitigate,  dianging  or  incomplete  ^ors  (both  internal  and 
external  forces)  that  influence  each  step  of  the  im];^ovement  process. 
Experience  has  shown  that  straight-line  (often  called  ‘’waterfall’*)  models  are 
not  effective  in  managing  sudi  dynamic  interactions. 

Though  process  improvement  activities  and  their  dates  cannot  be 
accurately  predicted  in  detail  far  in  advance,  a  well-structured  and 
executable  plan  can  be  developed  by  considering  a  set  of  core  activities  you 
can  plan  and  execute  in  an  iterative  manner.  Figure  3-1  presents  these 
steps: 

•  Step  1;  Understand  Context 

•  Step  2:  Analyze  Risks  and  Select  Strategy 

•  Step  3:  Plan  Improvements 

•  Step  4:  Implement  Improvements 

•  Step  5:  Review  and  Update 
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E^gureS-l.  Ftooess  Improvement  Ftocess 

These  steps  are  illustrated  as  a  cycle  to  portray  how  you  move  through 
them  (clockwise  movement  around  the  center),  continually  progressing 
(moving  away  from  the  center)  toward  your  goals.  In  each  t^de,  you  will 
develop  a  gocxl  understanding  of  your  current  situation,  identify  alterna* 
tive  ways  to  improve,  evaluate  risks,  successfully  plan  and  implement 
changes,  accurately  assess  progress,  and  plan  the  next  increment.  The 
process  recognizes  that  you  may  need  to  iterate  cycles  to  achieve  your 
objective. 

The  remainder  of  this  guideb(x>k  helps  you  manage  your  pr<x:ess 
improvement  process  using  this  successfrd  approach  based  on  the 
Evolutionary  Spiral  Process  described  in  Process  Engineering  With  the 
Evolutionary  Spiral  Process  Model  (Software  Productivity  Consortium 
1993b). 

3.2  A  MODEL  OF  PROCESS  IMPROVEMENT 

You  perform  prcxsss  improvement  repeating  the  five  steps,  vMch 
comprise  one  cyde,  using  the  knowledge  gained  and  lessons  learned  from 
previous  cydes.  Multiple  cydes  together  form  a  spiral  to  accomplish  a  spedfic 
objective,  sucfr  as  to  institutionalize  project  management  prindi^es. 

Figure  3-2  a  process  improvement  spiral  (starting  from  the  inside  and 
growing  out)  that: 

•  Highlights  the  main  activities  of  the  process  improvement  prcKess 
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•  Is  based  on  the  scenario  that  one  or  more  staff  members  (i.e^  chai^ 
agents  and/or  chami»ons)  decide  to  pursue  |vooess  improvement, 
without  management  initiation 

If  you  do  not  have  management  authorization  to  do  these  activities,  but 
still  want  to  champion  |»ocess  improvement,  perform  the  a<^tiM  in 
the  first  (^e  on  your  own  time. 


•  Shows  a  sj^al  being  spun  off  to  address  the  imidementation  of  a 
specific  process  improvement 


The  next  three  sections  provide  a  scenario  for  implementing  Cycle  1,  Cycle 
2,  and  Cycle  N  (all  subsequent  qrcles)  to  achieve  your  objective  of  process 
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improvement.  Appendix  A  i»ovides  three  dieckiists  that  support  this 
scenario,  and  lists  the  activities  and  tasks  that  should  be  perfcx’med  in  each 
cycle. 

Cycle  l:  Developing  an  lamtovEMENT  Plan 

In  the  first  cyde,  the  objective  is  to  develop  a  plan  for  imj^ovements  that 
will  be  used  in  a  later  c^e  to  get  management  support  and  funding.  The 
activities  in  the  first  cyde  su|^rt  this  by: 

•  Defining  alternative  improvement  strategies  (DefineAIpdate 
Imin-ovement  Strat^es  in  Step  1). 

•  Analyzing  the  risks  to  the  imiH^ovement  strategy  (Analyze  Risks  in 
Step  2). 

•  Skipf^  Steps  3  and  4  until  sponsorship  and  support  are  estaUidied. 

•  Defining  a  plan  for  how  to  proceed  (Han  Program  and  Define  Budget 
in  Step  5). 

Cycle  2:  Securing  Sponsorship 

The  objective  of  the  second  cyde  is  to  secure  management  support  for 
process  improvement  and  to  develop  the  needed  infrastructure  to  proceed 
with  improvements.  The  activities  in  the  second  Qrcle  support  this 
objective  by; 

•  Obtaining  explidt  management  support  and  funding,  and  confirming 
or  establishing  other  roles  for  process  improvement  (Build 
Sponsorship  and  Foundation  in  Step  1). 

•  Analyzing  and  resolving  risks,  as  needed,  based  on  the  sponsorship  and 
infrastructure  established  in  the  first  step  (Analyze  and  Resolve  Risks 
in  Step  2). 

•  Skipping  Steps  3  and  4  until  sponsorship  and  support  are  established. 

•  Updating  plans  and  budget,  and  planning  the  next  cycle,  when  the  first 
nonplanning  activities  will  be  performed  (Update  Program  Plans, 
Update  Budget,  and  Plan  Nod  Cycle  in  Step  S). 

If,  at  the  start  of  the  second  c^cle,  management  wanted  changes  to  the  plan 
before  supporting  it,  then  one  or  more  cydes  would  be  performed  to  incor¬ 
porate  these  changes.  As  in  any  process  improvement  effort,  however,  do 
not  proceed  with  implementation  until  management  commitment  and 
support  are  obtained.  If  management  is  committed  from  the  beginning, 
then  Cycles  1  and  2  can  be  combined. 


3-4 


3.  How  Do  You  Uic  the  Procew  laproweaeBt  Tnacml 


Cycle  N:  Implemenung  Process  Improvements 

From  the  third  cycle  on,  the  objective  is  to  implement  process 
improvements.  By  this  time,  a  plan  that  everyone  supports  has  been 
developed,  and  adequate  management  support  and  funding  has  been 
committed.  In  the  third  and  subsequent  c^des  shown  in  Figure  3-2,  each 
cycle  is  devoted  to  performing  an  assessment  and  focusing  on  im{»^oving 
those  process  areas  deemed  most  critical  to  improve.  The  activities  in 
these  cycles  support  process  improvement  by: 

•  Reinforcing  sponsorship  and  the  supporting  foundation,  defining^ 
updating  alternative  strategies  for  the  cycle  and  the  entire  prcKess  im¬ 
provement  strategy,  if  needed,  and  taking  another  look  at  the  process 
(Reinforce  Sponsorship  and  Foundation,  Update  Improvement 
Strategies,  and  Assess/Understand  Process  in  Step  1) 

•  Analyzing  and  resolving  risks  for  the  current  cycle  and  potentially  the 
spiral,  and  selecting  a  strategy  on  which  to  base  the  cycle  improve¬ 
ments  (Analyze  and  Resolve  ^sks  and  Select  Strategy  in  Step  2) 

•  Developing  a  detailed  plan  for  the  parts  of  the  process  to  be  improved 
in  the  current  cycle  (Plan  Cycle  Improvements  in  Step  3) 

•  Implementing  the  plan  for  this  cycle,  and  monitoring  and  managing 
the  improvements  (Implement  and  Manage  and  Monitor  in  Step  4) 

•  Reviewing  the  progress  of  the  cycle's  implementation,  updating  all  of 
the  plans  accordingly,  and  planning  the  next  cycle  (Review  Progress 
and  Update  Program  Plans,  Update  Budget,  and  Plan  Next  Cycle  in 
Step  5) 

3  J  USING  THE  PROCESS  IMPROVEMENT  PROCESS 

This  section  explains  how  the  process  is  described  in  subsequent  sections 
of  the  guidebook  and  provides  guidelines  on  how  to  use  the  process. 


Locating  Yourself  in  the  Process 

There  are  countless  ways  to  perform  process  improvement  using  this 
process.  Your  role,  your  organization’s  culture,  and  the  state  of  existing 
processes  affect  your  focus  and  scope  for  these  activities.  Because  of  this 
wide  range  of  possibilities,  the  guidance  in  this  guidebook  is  based  on  the 
scenario  outlined  in  Section  3.2. 

Many  situations  deviate  from  the  basic  scenario  outlined  in  this  guidebook. 
Your  organization  may  have: 
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•  Existwg  Sponsorship  and  CommitmaO.  \bu  mi^  already  have  a  ^xmsor 

is  committed  to  process  improvonent  Do  you  have  the  infiastmture 
in  i^aoe  to  supped  process  in^ovnnait?  you  identified  risks  to 
process  improvement?  Is  tho^e  an  action  plan  fiv  inqdonmting  process 
improvements? 

Review  the  guidance  for  C^les  1  and  2.  Depending  on  your  specific 
situation,  you  may  need  to  perform  some  activities  and  tasks  t^t  are 
desCTibed  in  these  cycles  to  identify  risks  to  your  process  improvement 
program  and  develop  a  plan  for  implementing  improvements.  If  you 
feel  confident  that  you  have  addressed  Cycle  1  and  2  issues,  continue 
with  Cfycle  N  guidance. 

•  Reeentfy  Conducted  an  Asxssment  of  Its  Processes.  In  tim  case,  you  raay 
need  assistance  with  the  steps  following  a  process  assessment.  Is  your 
sponsor  still  committed  to  implementing  improvements?  Is  a  Process 
Group  (PG)  in  place,  or  do  you  need  to  establish  one? 

Review  the  guidance  for  Cycles  1  and  2  concerning  the  infrastructure 
and  demonstrating  sponsorship,  and  perform  any  activifyyou  feel  nec¬ 
essary.  Follow  the  guidance  for  Cycle  N  in  this  guidebook  for  under¬ 
standing  your  implementation  risks,  developing  an  action  plan, 
implementing  the  plan,  and  reviewing  progress. 

•  Lost  Momauian  in  the  Proass  Improvement  Prs^^wnAth  not  uncovaiDon 
for  process  improvement  initiatives  to  lose  momentum  16  to  18  months 
after  a  formal  assessment  Has  your  sponsor  seen  inaemental  improve¬ 
ments?  How  has  the  organization  and  its  climate  dianged,  e.g.,  did  a  k^ 
stakeholder  leave?  Has  the  organization  raperienced  down-sizing?  Has 
funding  been  reduced? 

Your  best  bet  to  reenergize  the  process  improvement  program  may  be 
to  perform  Cycle  1  and  2  activities  again.  You  will  need  to  work  very 
hard  to  build  sponsorship  commitment  and  trust  fi-om  the  other  stake¬ 
holders,  since,  historically,  process  improvement  may  have  been  per¬ 
ceived  as  less  than  successful.  Sponsors  are  under  tremendous 
pressure  to  show  results,  so  set  realistic  expectations  and  implement 
small  improvements  to  build  trust  within  the  organization. 


Things  to  Know  before  Using  the  Process 

Understand  the  following  before  you  use  this  guidebook: 

•  The  process  guidance  focuses  on  the  group  or  individual  implementing 
the  improvement  activities  (the  change  agent). 

•  Sections  4  through  8  discuss  process  improvement  primarily  in 
proactive  terms,  though  the  activity  descriptions  are  also  useful  when 
dealing  with  a  reactive  improvement  process. 
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•  You  can  perform  eacb  activity  using  various  organizational  structures 
and  styles,  induding  formal  team  meetings,  infmmal  group  meetings, 
or  work  individuals.  How  you  perform  eadi  activity  depends  on  your 
own  style  and  your  organization’s  culture. 

•  Matty  activities  call  fw  "a  descriptkm  oC”  instead  a  specific 
doounentation  type.  The  document  can  be  handwritten  notes  cr 
word-processor  text— the  type  of  document  you  aeate  is  up  to  you  and 
your  mansgement  You  n^  to  capture  your  analyses,  decisions  and 
supporting  rationale,  and  in^ementation  efforts. 

•  Each  activity  is  accompanied  by  a  list  of  potential  measures  that  you 
can  gather  to  imfx^ove  your  process  improvement  process.  Calendar 
time,  effort  (i.e.,  staff  hours,  days,  or  months),  size,  and  quality  are  the 
measures  most  commonly  recommended.  Tliese  measures  provide  a 
foundation  for  continuous  process  improvement,  increase  your  accu¬ 
racy  in  future  estimation  efforts,  and  help  quantify  your  organization’s 
return  on  investment  (ROI). 

When  collecting  effort  data,  record  the  amount  of  time  spent  by 
different  levels  of  staff  (i.e.,  a  senior  manager  costs  more  than  a  staff 
engineer).  These  differences  should  be  captured  to  reflect  accurately 
the  cost  of  an  activity.  The  quality  of  intermediate  work  products  (e.g., 
plans)  may  be  best  measured  by  using  the  inspection  process. 

•  Use  existing  data  and  knov^edge  wherever  possible,  from  such  sources 
as  planning  exercises  and  process  improvement  experiences  of  your 
organization  and  peers. 


Who  Should  Perform  the  AcnvrriES? 

Since  staff  at  any  level  in  your  organization  can  play  a  role  in  process 
improvement,  this  guidebook  defines  these  organizational  roles.  Identify 
your  role(s)  for  any  particular  activity,  and  then  follow  the  guidance  for 
that  role.  The  role  icons  to  the  left  of  the  text  (shown  below  with  their 
respective  role  definitions)  help  to  identify  your  role(s)  quickly. 

^  •  Sponsor.  This  person  possesses  sufficient  authority  or  influence  either 

to  initiate  resource  commitment  for  process  improvement  (authoriz¬ 
ing  sponsor)  or  to  reinforce  process  improvement  efforts  at  the  local 
level  (reinforcing  sponsor).  Itoth  authorizing  and  reinforcing  sponsors 
continually  legitimize  and  demonstrate  ownership  and  commitment  to 
process  improvement.  The  departure  or  unavailability  of  sponsors 
could  jeopardize  the  success  of  an  improvement  activity  or  group. 

The  authorizing  sponsor  is  usually  the  senior  manager  of  the  organization 
and  often  serves  as  the  chairperson  of  the  Steering  Conunittee  (SC)  of 
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the  process  improvement  program.  Reinfcn'dng  sponsors  are  typcally  at 
a  middle-manager  level  and  are  members  of  the  SC. 

•  Chat^  Agent.  This  person  or  team  is  empowered  by  sponsors  to 
implement  and  facilitate  process  im|H^ovement  throi^out  the 
organization.  The  PG  and  the  Process  Action  Tbams  (PAR)  are 
considered  change  agents. 

•  Champion.  This  person  advocates  and  publicly  supports  process 
improvement  in  the  organization,  but  lacks  the  power  to  sanction  it  A 
champion  can  be  present  at  any  and  all  levels  of  an  organization; 
successful  champions  are  usually  respected  for  personal  or  technical 
leadership. 

•  Process  User.  This  group  of  people  uses  the  new  process  and  is  the  focus 
of  the  change  efifort  i.e.,  the  individuals  are  expected  to  change  the  way 
they  work,  and  therefore  their  behavior  or  emotions.  The  process  users 
are  those  people  who  develop  your  organization’s  software  products, 
typically  considered  the  technical  staff. 

These  roles  may  evolve  and  overlap  during  process  improvements.  For 
example,  a  senior  manager  may  need  to  be  i^uenced  by  a  champion  or 
change  agent  to  become  an  authorizing  sponsor.  Upon  authorizing  the 
proposed  change,  the  sponsor  may  champion  the  improvement  on  a  larger 
scale  and  to  other  organizations. 


How  Are  the  AcnvmEs  Formatted? 

Figure  3-3  presents  the  content  and  format  of  the  activity  descriptions  that 
appear  in  Sections  4-8.  Each  activity  description  includes  a  (^cle  in  the  left- 
hand  comer.  For  each  activity,  the  corresponding  step  in  the  cycle  context 
diagram  is  shaded.  Context  diagrams  are  also  included  in  the  page  headers 
of  Sections  4-8.  They  indicate  the  location  in  the  cycle  of  the  activity  under 
discussion. 
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ItacMiT 


Name  of  Activity 

A  Statement  of  udten  this  activity  is  performed. 

Overview 

Provides  an  overview  of  the  activity,  including  its 
objectives  and  any  interactions  with  other  activities. 

Start  Criteria 

IVovides  entrance  criteria  and  input  descripticris. 

Tasks 

Provides  a  detailed  descriptioa  cf  the  tasks  that  should 
be  performed  in  this  activity. 

A  role  icon  b  placed  next  to  the  first  line  each  task 

Mhen  the  corresponding  role  wiU  be  invdved  in  that 
task’s  performance.  The  guidance  is  written  fitmi  the 
change  agent’s  perspective. 

CycUN 

The  cycle  in  wfaidt  you  would  perform  this  activity  is 
indicated  in  the  left  margin  as  needed.  In  addition,  the 
guidance  includes  how  to  perform  this  activity  in  this 
cyde. 

Measures 

Provides  a  descri{Hion  of  measures  that  you  should  gather 
vdien  performing  this  activity. 

Stop  Criteria 

Provides  exit  criteria  and  output  descriptions. 

$  d  O-x**-  5  uT*  ^  ^ 

Figure  3-3.  Activity  Format 
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This  page  intentional  kfi  blank 
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4.  ESTABLISH  A  BASEUNE:  UNDERSTAND 

CONTEXT 


People  will  make  reasonable  decisions  if  they  are  given  proper  information. 

Thom  Serrani,  Mayor,  Stamford,  Connecticut 

An  effective  process  improvement  program  requires  a  reasonable 
understanding  of  the  current  status  of  the  organization  everyone.  The 
current  status  is  a  snapshot  of  both  the  tedinical  aspects  aixl  the  organization¬ 
al/cultural  aspects.  This  section  provides  guidance  for  the  activities  shown  in 
Figure  4-1. 


Section  Objective 

Provide  guidance  for 
understanding  your 
CMTTtnt  orgaruzational 
context 


Figure  4-1.  Understand  Context  Activities 
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4.1  BUILD/REINFORCE  SPONSORSHIP  AND  FOUNDATION 


This  activi^  begins  in  Step  1,  Understand  Context. 


Overview 

In  this  activity,  your  objective  is  twofold:  to  build  and  sustain  strong 
sponsorship,  and  to  create  an  organizational  foundation,  induding 
culture,  that  supports  successful  continuous  process  improvement 
programs.  This  activity  may  be  conducted  in  parallel  with  the  next  activity, 
Update/Define  Improvement  Strategies. 

Success  of  a  process  improvement  program  is  highly  dependent  on  the 
commitment  and  support  of  senior  management.  Before  launching  a  pro¬ 
cess  improvement  program,  senior  management  must  sanction  the  pro¬ 
gram  and  demonstrate  this  commitment  to  everyone  in  the  organization 
by  performing  the  “nondelegable”  tasks  describ^  in  this  activity. 

A  process  improvement  foundation  is  required  to  support  (x-ocess 
improvements.  This  foundation  indudes  organizational  readiness,  the  SC, 
and  the  PG.  Both  of  these  groups  represent  the  sponsors,  diampions,  and 
change  agents  who  support  process  improvements.  Chamixons  are  needed 
to  advocate  process  improvement  to  keep  peojde  supportive 
constantly  reinfordng  its  ^nefits.  Change  agents  are  needed  to  perform  the 
day-to-day  tasks  of  support,  implementation,  planning,  managing  and 
review.  Sponsors  must  continually  demonstrate  and  reinforce  commitment 


Start  Criteria 


Use  the  following  types  of  information  and/or  working  knovdedge  as 

inputs  to  this  activiQc 

•  Any  supporting  documents,  induding  prior  process  improvement  action 
plans  and  organizational  strategic  {dans  foat  are  related  to  jx^ocess 
improvement 

•  If  the  organization  is  continuing  process  improvement,  the  planning 
documents  created  and  updated  in  previous  cycles,  including  the  soft¬ 
ware  process  improvement  plan,  risk  management  plan,  action  plan, 
and  influence  strategy 

•  Any  historical  process  improvement  information 
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If  you  are  a  process  user,  champion,  or  potential  change  agent  within  your 
organization,  and  sponsorship  is  lacking,  find  someone  who  will  sponsor 
process  improvement,  lb  do  this,  view  the  change  as  building  manage¬ 
ment’s  awareness  and  belief  in  continuous  process  improvement.  Perform 
Ihsk  1  and  Ihsk  2  in  Cycle  1  with  this  idea  in  mind  until  you  have  found  an 
authorizing  sponsor,  and  build  intermediate  or  reinfordng  sponsors  con¬ 
tinuously  as  you  work  toward  this  objective.  Before  sponsorship  is  estab¬ 
lished,  the  amount  of  resources  you  can  expend  on  these  two  tasks  will  be 
limited  and  may  be  conducted  on  your  own  time.  Perform  them  to  the  best 
of  your  ability. 

Once  sponsorship  for  process  improvement  has  been  established,  perform 
these  tasks  in  parallel  with  tasks  in  the  DeiBneAJpdate  Improvement 
Strategies  activity. 

Understand  that  the  tasks  (except  for  Qrcle  1  tasks)  in  this  activity  are 
nondelegable  tasks — ^they  must  be  conducted  by  the  sponsor.  Assist  the 
sponsor  in  any  way  possible,  but  the  message  to  the  organization  must 
come  from  the  sponsor. 

1.  Understand  Implementation  Climate  and  Organizational  Readiness. 
You  need  to  understand  the  organization’s  history  of  process  improvement 
and  the  readiness  of  all  stakeholders  to  undertake  process  improvement. 
In  this  task,  survey  as  many  potential  stakeholders  as  possible  to 
understand  their  perceptions  of  the  following: 

•  Success  of  Past  Process  Improvement  Initiatives.  Previous  unsuccessful 
attempts  at  process  improvement  tend  to  decrease  the  credibility  of 
the  sponsors  and  increase  the  resistance  in  stakeholders. 

•  Current  Level  of  Stress  in  the  Organization.  Stress  within  an  organization 
can  impact  your  process  improvement  program.  Some  sources  of 
stress  are  positive  motivating  forces  for  the  program,  such  as  a  lost  con¬ 
tract  opportunity,  while  some  are  less  motivating,  such  as  downsizing 
or  a  hostile  takeover.  Higher  levels  of  stress  require  more  resources 
to  manage  and  implement  process  improvement  successfully. 

•  Culture  of  the  Organization.  Process  improvement  efforts  that  are 
aligned  with  the  organizational  culture  have  a  greater  chance  of  suc¬ 
cess  than  those  that  are  not.  When  improvement  efforts  are  counter  to 
the  existing  culture,  the  culture  always  prevails. 

•  Degree  and  J^pe  of  Commitment  of  Sponsors.  The  degree  and  type  of 
commitment  of  executives,  senior  management,  and  middle 
management  are  important  indicators  of  improvement  success. 
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•  Concerns  of  the  Process  Users.  Resistance  is  inevitable.  Listen  to  and 
understand  process  users  concerns  about  the  change  and  its 
consequences,  so  that  you  can  better  manage  their  expectations. 

•  AbUity  of  the  Charge  Agents.  These  people  must  have  the  proper  skills, 
respect,  support,  and  responsibility  to  be  effective  in  their  positions. 
One  key  sldll  that  is  needed  is  a  deep  understanding  of  human 
reactions  to  change. 

A  general  rule  of  thumb  is  that  if  the  climate  is  strong  (good  history  and 
low  stress),  then  fewer  resources  will  be  needed  to  build  organizational 
readiness  (culture,  sponsors,  process  users,  and  change  agents).  Converse¬ 
ly,  if  the  climate  is  weak  (poor  history  and  high  stress),  you  will  need  more 
resources  to  build  organizational  readiness.  The  information  gathered  in 
this  task  is  used  in  Thsk  2. 

Cycle  1  At  this  point  in  the  process,  you  will  have  limited  resources  (time,  money, 

people)  to  expend  on  performing  this  task.  The  methods  you  use  to  gather 
this  information  will  be  informal  and  nonintrusive  in  nature.  It  is  too  early 
in  the  process  to  know  specifics  about  what  will  change,  so  concerns  of  the 
process  users  and  ability  of  the  change  agents  cannot  be  gauged  at  this 
time. 


Cycle  2  Once  you  have  identified  a  strong  sponsor,  more  resources  may  be  used 
to  gather  this  information.  The  methods  you  use  will  be  more  formal  and, 
ideally,  quantitative  in  nature.  It  may  be  wise  to  get  an  external  consultant 
with  expertise  in  organizational  change  to  perform  this  task. 

If  the  organizational  climate  is  not  conducive  to  change,  or  the  readiness 
of  the  stakeholders  is  low,  consider  these  as  risks  to  your  process 
improvement  program  and  address  them  in  the  next  step  of  the  cycle. 

Cycle  N  If  a  change  has  occurred  in  your  organization  that  would  affect  its  readiness, 

you  may  need  to  reassess  these  factors.  For  example,  if  your  sponsor  leaves 
the  organization  and  a  replacement  is  brought  in,  this  may  affect  not  onfy  the 
perception  of  sponsor  commitment,  but  also  organizational  stress. 


$ 


2.  Prepare  and  Execute  Influence  Strategy.  lb  maximize  the  probability  of 
successful  process  improvements,  you  need  to  develop  an  influence  strate¬ 
gy  to  communicate  to  the  organization  what  process  improvement  is,  why 
it  is  needed,  what  it  will  be  like  after  the  improvements  are  made,  what 
path  you  will  take  to  get  there,  etc.  Perform  the  following  subtasks: 


•  D^ne  Charge  and  Identify  Stakeholders.  For  all  the  roles  in  process 
improvement,  identify  why  they  should  support  process  improvement, 
what  the  change  will  mean  to  them,  and  what  will  not  change,  and  the 
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potential  peofrie  in  the  organization  who  will  fall  into  that  role.  Figure 
4-2  shows  a  sample  matrix  that  can  be  used  to  gather  this  information. 


F1gure4-2.  Define  the  CSiange  in  Stakeholder’s  Irame  of  Referenoe 

As  you  identify  what  will  and  will  not  change,  remember  to  consider 
the  stakeholder's  frame  of  reference.  By  understanding  the  point  of 
view  of  the  stakeholder  group,  you  can  identify  potential  resistance. 

Another  way  to  identify  stakeholders  is  to  obtain  a  current  organization 
chart  and,  using  four  or  five  different  highlighter  colors,  identify  the  spon¬ 
sors  (both  authorizing  and  reinforcing),  champions,  change  agents,  and 
process  users. 

•  Develop  Sponsor  Profiles.  For  all  potential  authorizing  and  reinfordng 
sponsors,  from  most  senior  management  to  immediate  supervisors  of 
process  users,  gather  the  following  information: 

-  What  is  their  attitude  toward  process  improvement?  What  is  their 
awareness  of  process  improvement  activities  and  resources 
required? 

-  lb  whom  do  they  report?  Whom  do  they  go  to  for  counsel?  Who 
goes  to  them  for  counsel?  Does  anyone  in  the  process  user  group 
influence  them? 

-  What  about  process  improvement  might  interest  them? 

-  What  is  their  communication  style?  Are  they  ROI-driven? 
technology-driven?  people-driven? 

-  Where  are  the  sponsors,  both  authorizing  and  reinforcing,  located 
on  the  organization  chart?  Where  do  the  potential  process  users, 
champions,  and  change  agents  fit,  in  relation  to  the  sponsors? 

Rank  the  list  of  sponsors  (both  authorizing  and  reinforcing),  from  the 
easiest  from  whom  you  are  likely  to  gain  buy-in  to  the  most  difficult. 

•  Understand  Stakeholder  Rdationships.  A  successful  influence  strategy 
will  take  into  consideration  the  relationships  among  the  stakeholders. 


4.  Bslablith  •  Baseline:  Undetsiand  Conleit 

Figure  4-3  shows  three  common  stakeholder  relationship  scenarios 
(Conner  1993).  Which  scenario  best  reflects  your  situation? 


Figure  4-3.  RdeRelatioash^ 

-  Scenario  1.  This  is  the  typical  hierard^  organization.  The  sponsor 
may  successfully  cascade  some  of  his  sponsorship  duties  to  the 
diange  agent  The  process  users  view  the  change  agents  as  extensions 
of  the  sponsors. 

-  Scenario  2.  If  the  sponsor  delegates  sponsorship  duties  to  the 
change  agents,  the  process  users  are  more  apt  to  resist.  For  this 
structure  to  be  successful,  the  sponsor  needs  to  emphasize  his  com¬ 
mitment  to  process  improvement  and  introduce  the  change  agents 
as  the  group  diosen  to  guide  the  process  improvement  efforts.  This 
demonstrates  unequivocal  commitment  and  reduces  resistance. 

-  Scenario  3.  This  structure  poses  a  challenge.  If  the  sponsor  (Sponsor 
A)  and  the  diange  agents  want  any  glimmer  of  success,  th^  must 
convince  the  process  users'  sponsor  (Sponsor  B)  that  process 
improvement  is  imperative.  Un^  then,  resistance  will  occur. 

Examining  an  organization  chart  is  one  way  to  understand  relationships, 
but  most  communication  cxxxirs  in  a  less  formal  structure.  It  may  be  help¬ 
ful  to  develop  advice,  trust,  and  communication  relationship  networks,  as 
described  by  Krachhardt  and  Hanson  (1993). 

•  Develop  an  Ipfluenu  Strategy.  V^th  all  the  information  gathered  above, 
develop  a  "sales  ptch,”  using  the  most  appropriate  means  in  your 
organization  (e.g.,  presentation,  white  paper,  electronic  mail,  newsletter) 
to  communicate  with  the  stakeholders.  Support  from  the  stakeholders 
will  not  occur  without  sudi  communication.  This  strategy  should  indude: 
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-  Motivatk»  section  to  help  the  stakeholden  unfreeze 

-  >^sion  of  the  desired  state,  i.e^  what  the  wganization  will  *^ecr 
like  after  improvements  are  made 

-  Outline  of  the  transition  steps  to  adiieve  the  viskm 

Hgure  4-4  shows  two  grajdiics,  based  <m  the  three-stage  modd  of 
change  shown  in  Rgure  24,  that  can  be  used  to  sununarize  the 
information  you  put  into  your  influence  strat^. 

Cycie  1  Your  main  focus  in  this  (yde  is  to  develop  an  influence  strata  to  convince 

someone  in  senior  management  (a  potential  sponsor)  that  {M-ocess  im¬ 
provement  is  valuable  and  worthy  of  resource  investment  Spend  most  of 
your  time  identifying  potential  authorizing  and  reinforcing  sponsors.  Be¬ 
gin  informing  some  {M-ocess  users  of  the  process  improvement  effort.  Be 
selective  in  the  amount  of  information  you  share  and  with  u4)om:  you  want 
to  decrease  the  possibility  of  someone  sabotaging  your  efforts  before  you 
have  gotten  off  the  ground. 

Cycle  2  Once  you  have  identified  a  sponsor,  focus  on  cascading  sponstMship  (from 
senior  management  to  process  user  supervisors)  and  establishing  buy4n  from 
all  stakeholders  in  the  organization,  espedalfy  process  users.  The  influence 
strata  you  use  here  can  be  used  in  t^  sub^uent  task  of  demonstrating 
sponsorship  and  commitment 

Cycle  N  As  you  learn  more  about  eadi  stakeholder  group  in  your  organization,  it 
may  be  necessary  to  revise  your  influence  strategy.  Not  only  can  you  use 
this  influence  strategy  within  your  organization,  you  can  use  it  to  influence 
your  parent  or  peer  organization. 

3.  Demonstrate  Sponsorship  and  Commitment  Sponsors  can  demonstrate 
commitment  performing  the  following  nondel^able  actions: 

•  Set  Chattai^ng  Coals  to  Ensure  Process  Improvement.  It  is  crudal  fcv 
senior  management  to  set  reasonable,  diaUenging  goals.  These  goals 
should  be  attainable,  but  the  organization  should  have  to  “stretdi” 
moderately  to  meet  them. 

•  Provide  Necessary  Resources.  Sponsors  need  to  invest  in  learning  and 
communication.  Brown-bag  lunches,  guest  speakers,  or  video  presen¬ 
tations  are  means  for  an  organization  to  raise  the  level  of  awareness 
and  start  to  communicate  better.  Briefings  should  be  conducted 
periodically  to  inform  personnel  of  the  progress  of  the  process 
improvement  activities. 
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Figure  4-4.  Gr^>hics  for  Communicating  Change 


Momtor  Progress.  Senior  management  can  provide  visible  support  and 
maintain  the  seriousness  of  the  program  ^  monitoring  its  progress. 
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Reward  Success,  But  Do  Not  Punish  Failure,  The  purpose  of  process 
improvement  is  to  fix  the  process,  not  the  people.  Reward  those  wiio 
contribute  to  the  process  improvement  efforts.  Look  upon 


less-than-suocessful  eiSbrts  as  valuable  lessons  learned.  Punishment 
only  serves  to  stifle  people's  motivation  and  involvement 

•  BuUda  Culture  of  Improvement.  Sponsors  should  create  an  atmosphere 
of  continual  diange  and  improvement  The  organization  that  berames 
adept  at  handling  diange  is  better  poised  to  continue  to  imiwove  the 
way  it  does  business  and  to  remain  successful  and  competitive  in  its 
market. 

Cycle  1  A  sponsor  has  not  yet  been  identified  to  perform  this  task. 

Cycle  2  Use  the  influence  strategy  created  in  the  previous  task  as  a  vehide  to 
demonstrate  commitment  Communicate  this  influence  strategy  to  the 
organization  stakeholders.  Pick  three  to  five  main  points  of  the  influence 
strategy  (such  as  the  existing  state,  the  desired  state,  and  the  costs  of  not 
changing)  and  mention  these  when  talking  to  anyone  in  the  organization 
about  process  improvement.  Short,  consistent  messages  help  to 
demonstrate  commitment  and  build  trust  in  the  stakeholders. 

If  you  doubt  whether  sponsorship  can  be  sustained  throughout  the 
improvement  Qrcle,  do  not  proceed  any  further.  Instead,  execute  another 
(^cle,  focusing  on  strengthening  sponsorship. 

Cycle  N  Continue  to  reinforce  the  importance  of  process  improvement  by  using  the 

influence  strategy.  Also  stress  the  progress  made  to  date  and  the  resulting 
benefits. 

4.  Form  a  Steering  Committee.  The  role  of  the  SC  is  to  guide  process 
improvement  in  the  organization,  based  on  the  knowledge  of  its  members 
of  high-level  organizational  issues.  This  committee  cannot  be  formed  until 
a  sponsor  has  been  identified. 

Membership  of  the  SC  should  consist  of  the  sponsor,  middle  managers 
from  each  major  software  group  or  division  within  the  organization,  and 
the  PG  leader.  The  SC  should  meet  on  a  regular  basis,  either  monthly  or 
quarterly,  and  provide  progress  reports  to  the  overseeing  manager.  The  re- 
sponsibili^  of  the  SC  chair  should  be  rotated  on  a  per  iodic  basis  among  the 
members,  but  initially  the  senior  manager  is  the  chairperson. 

See  Section  6,  Chart  a  Course:  Plan  Improvements,  for  specific  details  on 
the  duties  of  the  SC. 

Cycle  1  A  sponsor  has  not  yet  been  identified  to  perform  this  task. 

Cycle  2  Involve  the  SC  early  in  subsequent  planning  and  commitment  activities. 

Since  the  SC  is  considered  a  sponsor,  its  members  should,  as  do  other 
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sponsors,  (vomote  the  same  three  to  five  key  points  from  the  influence 
strategy. 

Spend  time  on  building  a  strong,  (fynamic  team  to  inaease  its  effectiveness, 
lliis  group  is  very  visiUe  and  should  demonstrate  spcMisor^p.  If  the  team 
is  percei^  as  ineffective  mr  (iysfunctional,  the  process  improvement 
fvogram  will  not  be  p^ceived  positive^. 

Cyck  N  At  the  start  of  each  cyde,  evaluate  membership  on  the  SC  for  fit  to  the  focus 

of  the  current  cyde.  Ccmsider  rotating  the  chai^rscm  role  so  that  others  can 
be  seen  as  a  sponsm:  and  leader.  As  members  leave  the  SC,  recognize  and 
reward  their  efforts  and  oxitributions.  This  acknowledgment  may  be  as 
simile  as  a  {daque  for  outstanding  contribution  or  a  monetary  rews^. 

If  there  is  a  turnover  in  SC  members,  perform  some  additional  team  building 
oterdses  to  set  the  stage  for  the  new  members.  Refer  to  Sdioltes  (1988)  for 
guidance  on  team  building  exercises. 

5.  Establish  a  Process  Group.  This  group  cannot  be  formed  until  a  sponsor 
who  fully  supports  the  process  improvement  has  been  identified.  The  PG 
is  the  focal  point  for  software  process  improvement  and  works  with  manag¬ 
ers  and  engineers  to  improve  the  process  capability  of  an  organization.  The 
PG  should  report  to  senior  management,  throu^  the  SC,  and  should  be 
recognized  as  having  authority  to  effect  change. 

The  recommended  PG  staffing  level  should  be  between  1%  and  3%  of  the 
software  engineering  department.  Staffing  can  be  done  by  permanent  as¬ 
signment,  part-time  assignment,  temporary  assignment,  or  a  combination 
of  these.  TTiere  needs  to  be  at  least  one  permanent  member  of  the  PG, 
however,  to  maintain  continuity  and  focus.  The  permanent  member  is  con¬ 
sidered  the  PG  leader. 

The  suggested  guidelines  for  selecting  the  PG  leader  are: 

•  Recognized  as  a  Leader  Within  die  Organization.  This  person  is  the  liaison 
among  senior  management,  middle  management,  and  the  process  users. 

•  Eq>erien^inAllPhaxsofSopvareDevdopntent.TlmpeTSOTiTrmttmt 
a  clear,  detailed  understanding  of  the  organization’s  process  and 
practices. 

•  Advoa^of  Process  Improvement  and  TQMPrincipks.  Senior  management 
and  engineers  (process  users)  within  the  organization  may  continuous^ 
diallenge  or  resist  process  imjn’ovement  activities.  The  PG  leader  needs 
to  reaffirm  the  importance  and  value  of  process  improvement 
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•  Team  Leader  or  Partidpant  ia  the  Process  Assessmeat.  Ideally,  the  PG 
leader  functions  as  the  leader  of  the  process  assessment  team,  thus 
demonstrating  leadership  to  the  organization. 

•  Experienced  in  Project  Management.  The  PG  leader  is  the  main  focal 
point  for  overseeing  the  process  improvement  steps.  The  PG  leader 
also  coordinates  and  manages  the  activities  of  the  PAI^ 

•  Strong  Tham  Building  and  Team  Dynamics  SkiOs.'TlxPGleadeTvorksvnih 
groups  that  are  formed  m  assist  in  process  improvement  activities. 

Other  members  of  the  PG  should  be  practicing  software  {vofessitmals.  Th^ 
may  have  develoi»nent  or  support  rdes.  The  current  focus  ctf  the  PG  is  to 
{M^ovide  guidance  for  selecting  the  skill  sets  these  members  need  to  possess. 
For  example,  if  the  current  focus  of  the  PG  is  improving  project  management 
practices,  then  its  members  should  have  a  go^  understanding  of  project 
management  concepts  and  prindi^es. 

A  PG  could  potentially  exist  at  many  layers  in  an  organization,  depending 
on  its  size  and  organizational  structure,  '^ically,  there  is  one  PG  per  func¬ 
tional  organization,  i.e.,  an  organization  whose  products  are  built  for  one 
functional  area,  such  as  Management  Information  Systems  and  real-time 
embedded  systems.  You  may  also  have  a  PG  for  each  project  within  an  or¬ 
ganization  or  a  PG  aaoss  several  fimctional  areas,  though  these  are  less 
common.  Things  to  consider  when  several  PGs  exist:  Does  eadi  have  a 
clear  purpose  (charter),  or  will  they  be  stepping  on  eadi  other’s  toes? 
Whom  do  they  report  to?  What  are  their  spheres  of  influence? 

See  Section  6,  Chart  a  Course:  Plan  Improvements,  for  spedfic  details  on 
the  PG’s  duties. 

Cycle  1  In  Cycle  1,  you  have  not  identified  a  sponsor,  so  a  PG  cannot  be  formed. 

Cycle  2  Involve  the  PG  (duuige  agents)  early  in  subsequent  planning  and 

commitment  activities.  Since  the  PG  is  the  main  fo^  point  for  p-ocess 
im(»'ovement  implementation,  its  members  should,  as  do  other  sponsors, 
promote  the  same  three  to  five  points  from  the  influence  strategy.  The 
sponsors  should  formally  recognize  and  introduce  to  the  organization  the 
members  of  the  PG. 

Spend  time  on  building  a  strong,  (fynamic  team  to  maximize  its  effectiveness. 
This  group  is  very  visible,  it  has  been  sanctioned  by  senior  management  to 
implement  process  improvement  If  need  be,  provide  the  members  of  the  PG 
with  communication  and  consulting  skills  trainii^.  If  the  team  is  perceived  to 
be  ineffective  or  dysfunctional,  the  process  improvement  program  will  not  be 
pjerceived  px>sitively. 

Q/de  N  At  the  start  of  each  cyde,  evaluate  the  membership  of  the  PG  in  terms  of  fit 

to  the  current  cycle  focus.  The  PG  leader  role  may  be  rotated,  but  beware  of 
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too  frequent  rotations;  you  may  lose  oondnui^  from  one  cycle  to  the  asxL  As 
members  leave  the  PG,  recognize  and  reward  their  efiforts  and  ocmtributions. 
This  admowledgment  may  be  as  sim|de  as  a  {daque  for  outstandii^ 
contribution,  a  monetary  reward,  ot  promotitm.  This  both  demcmstrates  to 
others  that  you  value  the  efforts  of  the  PG  and  encourages  members  the 
group  to  become  more  actively  invcdved  with  process  improvement 

If  there  is  a  turnover  in  PG  members,  perform  some  additional  team  building 
aerdses  to  set  the  stage  for  the  new  members.  Refer  to  Scholtes  (1988)  fi»’ 
guidance  on  team  building  exercises. 


In  order  to  quantify  resources  spent  on  process  improvement  and  to  improve 
the  process  improvement  process  itself,  collect  the  following  measures: 

•  Time  and  effort  spent  understanding  the  implementation  climate  and 
organizational  readiness 

•  Size  of  organization,  in  persons  and  organizational  units 

•  Time  and  effort  spent  developing  an  influence  strategy 

•  Size  of  influence  strategy  (e.g.,  pages  or  charts) 

•  Quality  of  the  influence  strategy 

•  Size  of  the  SC 

•  Size  of  the  PG 

•  Cost  of  external  consultant  engaged  to  assist  with  understanding  the 
implementation  climate  and  organizational  readiness,  if  any 


This  activity  is  complete  when: 

•  You  have  prepared  an  influence  strategy  and  documented  it  in  the 
form  most  appropriate  for  your  organization,  possibly  a  presentation 
or  white  paper 

•  You  have  secured  adequate  sponsorship  to  suj^rt  process  improvement 

•  You  understand  the  current  climate  of  the  organization 
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•  YcxiuiKlerstand  the  levd(^stakehc4der  readiness  for  {xocessin^vovemeitt 

•  Both  the  SC  and  PG  have  been  established 

If  you  doubt  whether  sponsorship  can  be  sustained  throughout  the 
improvement  cycle,  you  have  two  alternatives.  First,  you  could  execute 
another  cycle,  focusing  on  strengthening  sponsorship.  Second,  if  your 
sponsor  is  willing  to  commit  to  a  formal  soft«^e  process  assessment,  then 
you  could  proceed  and  use  that  assessment  to  solidify  sponsorship.  If  you 
choose  to  proceed  with  an  assessment  without  adequate  sponsorship,  you 
increase  the  risk  of  implementation  failure,  which  incurs  both  short-term 
costs,  such  as  wasted  resources,  and  long-term  costs,  such  as  reduced 
confidence  in  leadership. 
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42  DEHNE/UPDATE  IMPROVEMENT  STRATEGIES 


This  activity  begins  in  Step  1,  Understand  Context. 


Overview 

In  this  activity,  your  objective  is  to  define  and  update  the  process 
improvement  program  objectives,  alternatives,  and  constraints  that  are 
consistent  with  the  needs  and  current  environment  of  your  organization. 
Once  the  process  improvement  program  has  sponsorship,  you  will  develop 
the  objectives,  alternatives,  and  constraints  for  the  current  (^cle. 

Before  you  can  define  your  process  improvement  strategy,  you  need  to 
understand  the  environmental  issues  that  may  influence  the  process 
improvement  program.  Alternatively,  you  may  provide  some 
retrospective  validation  for  decisions  that  have  already  been  made. 
Document  your  findings  and  justifications  for  recommendations  in  this 
activity,  many  of  the  issues  and  concepts  change  rapidly  or  are  perceived 
differently  by  different  people. 

With  the  information  identified  in  this  activity,  you  can  influence 
stakeholder  expectations  about  the  purpose  of  the  process  improvement 
program,  as  well  as  the  purpose  of  the  current  cycle.  For  this  reason,  you 
may  choose  to  perform  this  activity  in  parallel  with  the  previous  activiy, 
Build/Reinforce  Sponsorship  and  Foundation,  during  Cycles  1  and  2. 

In  Cycle  N,  this  activity  is  typically  performed  after  an  assessment  of  the 
current  state  of  your  organization’s  software  process.  This  allows  you  to 
customize  thr-  cycle  objectives  to  the  findings  and  recommendations  firom 
an  assessment. 


Start  Crderia 


Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Internal  environment  information,  including  any  strategic  plans, 
process  improvement  dcx:uments,  and  analysis  of  your  organization’s 
work  force  (e.g.,  demographics,  skills) 

•  External  environment  information,  including  easting  organizational 
documents  on  prcx«sses  and  tec^olc^es  (e.g.,  trip  reports,  benchmark 
studies),  market  surveys,  comparison  data  with  peer  organizations, 
competitor  information,  and  relevant  laws,  regulations,  or  standards 
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•  If  you  are  involved  in  a  continuing  {M'ocess  improvement,  the  planniitg 
documents  created  and  updated  in  {devious  (^es,  induding  the 
process  improvement  plan,  risk  management  [dan,  action  plan,  and 
influence  strategy 

•  The  findings  and  recommendations  report  from  the  most  recent 
assessment 

•  Any  historical  process  improvement  information 


You  wiU  define  or  update  your  process  improvement  in^ogram  objectives,  as 
well  as  your  cyde  objectives,  identify  alternative  ways  to  meet  your  objectives, 
and  identify  constraints  on  your  process  improvement  prpgram. 

1.  Define/Update  Objectives.  An  objective  is  an  intended  or  desired  result 
of  a  course  of  action.  It  is  better  to  write  several  independent  objectives 
than  to  pack  everything  into  one  statement;  this  fadlitates  progress  review 
and  simplifies  tradeoff  analysis.  A  rule  of  thumb  is  that  each  objective  may 
be  met  independently  of  the  success  or  failure  of  any  other  objective. 

These  are  some  characteristics  of  a  good  objective: 

•  Meets  Stakeholder  Win  Conditions.  The  objective  recondles  conflicting 
expectations  and  creates  reasonable  winning  conditions  for  all. 

•  Results  Oriented.  The  objective  describes  the  desired  result,  not  the 
means  to  achieve  it. 

•  Trackable.  Progress  toward  the  objective  is  determined  by  tracking 
measurable  goals  that  support  the  objective. 

•  Clear  and  Concise.  The  objective  can  be  stated  in  20  or  fewer  words. 

•  Controllable.  It  is  possible  to  influence  how,  whether,  and  to  what 
degree  the  objective  is  met. 

•  Realistic.  It  is  possible  to  achieve  the  objective,  given  current  information 
and  resources. 

•  Appropriate.  The  objective  is  well  suited  to  the  current  level  of  abstraction. 
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Cycle  1  Identify  your  organization’s  strategic  objectives  of  process  imfvovement, 

such  as  “achieve  maturity  Level  3  within  two  years”  or  “achieve  a  tenfold 
increase  in  quaUty,  as  perceived  by  our  customers,  in  five  years.”  Base 
these  objectives  on  your  perception  of  senior  management’s  objectives. 

Your  (^cle  objectives  will  focus  on  both  creating  a  process  improvement 
program  strategy  and  estimating  the  amount  of  resources  needed  to 
undertake  process  improvement  activities. 

Cycle  2  Work  with  your  (potential)  sponsor  and  the  SC  to  refine  your  organization’s 

strategic  objectives  for  process  improvement 

Your  cyde  objectives  will  focus  on  identifying  the  key  roles  of  process 
improvement  and  potential  stakeholders  to  perform  these  roles,  as  discussed 
in  the  BuQd/Reinforce  Sponsorship  and  Fbundation  activify. 

Cycle  N  Update,  if  needed,  the  organizational  objectives  for  the  process 
improvement  program,  based  on  feedback  from  the  sponsors  and  any 
findings  from  an  assessment 

Your  current  cycle  objectives  will  typically  focus  on  improving  part(s)  of 
your  software  process,  based  on  the  major  areas  of  improvement  from  the 
assessment  recommendations.  For  example,  you  may  identify  five  cycle 
objectives: 


•  To  improve  software  project  management  practices 

•  lb  improve  requirements  management  practices 

•  lb  formalize  review  processes 

•  To  institutionalize  software  quality  assurance  practices 

•  To  install  configuration  management  practices 

2.  Identify  Alternatives.  Identify  various  ways  to  achieve  your  objectives. 

Document  the  following  information  for  each  alternative  identified: 

•  An  outline  that  discusses  how  the  alternative  might  accomplish  the 
objectives 

•  Any  interdependencies  among  the  alternative  and  other  previous 
alternatives  that  may  have  been  committed  to 

•  An  estimate  of  the  resources  (e.g.,  people,  information,  time,  materials, 
equipment)  required  the  alternative 
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•  An  estimate  of  the  confidence  (lack  of  risk)  in  the  estimates 

•  An  estimate  of  any  additional  benefits  and/or  opportunities 

Cycle  1  Consider  all  viable  alternatives  to  attaining  your  strategic  objectives.  For 
example,  if  your  strategic  objective  is  to  "achieve  a  tenfold  increase  in  qual- 
i^,  as  perceived  by  our  customers,  in  five  years,”  your  alternatives  may  be 
to  institute  a  reuse  adoption  program,  institute  TQM  principles,  and 
improve  process  maturity  using  the  CMM. 

In  C^cle  1,  yotir  cycle  objective  is  to  develop  a  plan  that  you  will  use  to 
establish  sponsorship. 

Cycle  2  Work  with  your  (potential)  sponsor  to  identify  ai^  other  alternatives  for 
adiieving  your  organization’s  strategic  objectives  for  {H'ocess  improvement. 

Your  cycle  alternatives  will  identify  ways  to  understand  and/or  assess  your 
process.  Your  alternatives  may  indude  conducting  a  formal  assessment  of 
your  organization  and  performing  a  less  rigorous  appraisal  of  a  smaller 
part  of  your  organization  or  process.  Refer  to  Appendix  B  for  information 
concerning  various  ways  of  assessing  and  understanding  your  software 
process. 

Cycle  N  Assuming  your  program  objectives  have  not  changed  significantly,  identify 
and  document  any  viable  alternative  ways  to  implement  your  cyde  objectives. 

For  example,  you  may  identify,  at  a  very  high  level,  the  scheduling  and 
resource  assignment  alternatives,  shown  in  Figure  4-5,  for  achieving  the 
five  cycle  objectives  identified  in  Thsk  1. 

3.  Identify  Constraints.  Constraints  are  imchangeable  considerations  that 
alternatives  must  satisfy.  Your  constraints  may  come  from: 

•  External  Influences.  Your  organization  may  be  part  of  a  larger  business 
organization  that  imposes  expectations  and  constraints.  The  customer 
may  also  pose  constraints  on  your  organization. 

•  Limited  Resources.  Your  organization  may  be  limited  by  its  availability 
of  skilled  personnel,  development  time,  and  available  funding. 

•  Existing  Technology.  Your  organization  may  be  bound  by  existing 
technologies,  such  as  reusable  parts,  commerdal  off-the-shelf  (COTS) 
products,  and  software  development  methods. 

•  Standards.  The  parent  organization  or  a  customer  may  impose  standards 
to  follow  and/or  activities  to  conduct. 
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Cycle  1  Identify  and  document  constraints  on  your  alternatives  to  achieve  your 
strategic  objectives. 

Q^le  2  Your  constraints  during  this  Qrcle  typically  reduce  the  number  of  software 

process  assessment  alternatives  to  one. 

In  most  instances,  certain  constraints  on  your  assessment  methods  narrow 
down  your  alternatives  to  just  one.  Pbr  exampde,  your  organization  may  have 
a  contract  with  a  requirement  to  demonstrate  CMM  Level  3  diaracteristics, 
or  you  may  be  competing  in  Europe  and  must  be  compliant  with  the  ISO 9000 
standards. 

Cycle  N  Review  the  constraints  on  your  process  improvement  j^ogram  and  update, 
as  needed.  Identify  and  document  the  constraints  on  your  cyde  alternatives. 

If  your  process  improvement  program  is  new  or  revitalized,  you  may  want  to 
constrain  your  cycle  objectives  to  one  or  two  process  area  im|M'Ovements.  This 
provides  you  the  opportunify  to  adiieve  one  or  two  small  successes,  whidh 
inaeases  stakeholder  buy-in  and  commitment 


Measures 

In  order  to  quantify  resources  spent  on  process  imix'ovement  and  to  imin-ove 
the  process  improvement  process  itself,  collect  the  following  measures: 
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•  Time  and  effort  spent  defining  and  updating  your  objectives 

•  Time  and  effort  spent  identifying  alternatives 

•  Time  and  effort  spent  identifying  and  reviewing  constraints 

•  Numbo'C^  objectives,  alternatives,  and  constraints  that  are  new,  modified, 
CM*  reused  as  is 


Stop  Criteria 

This  activity  is  complete  when: 

•  You  have  prepared  a  description  of  your  organization’s  objectives  and 
constraints  for  the  process  improvement  program  and/or  for  the  cycle. 
These  objectives  and  constraints  are  based  on  a  current  understanding 
of  your  external  and  internal  environments. 

•  You  have  prepared  a  description  of  alternative  strategies  for  achieving 
your  qrcle  objectives. 

•  In  the  first  cycle,  you  have  identified  alternative  process  improvement 
strategies  that  should  be  considered  for  the  program. 
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43  ASSESS/UNDERSTAND  THE  PROCESS 


This  activity  begins  in  Step  1,  Understaiul  Context 


Overview 

Your  objective  in  this  activi^is  to  conduct  an  assessment  the  oiganizatioD’s 
l^ocesses  to  identify  and  understand  the  critical  sc^tware  issues.  The  main 
objectives  of  a  softv^e  fx-ocess  assessment  are: 

•  lb  understand  how  the  organization  operates 

•  lb  identify  key  areas  for  improvement 

•  lb  enlist  organization  stakeholders  in  the  change  process 

You  will  use  the  assessment  strategy  selected  in  the  previous  (^de  in  Step 
2,  Analyze  Risks  and  Select  Strategy. 

None  of  these  tasks  are  performed  until  you  have  achieved  sponsorship 
and  received  approval  on  the  improvement  program  strategy  defined  in 
previous  (^cles.  Therefore,  all  of  the  guidance  in  these  tasks  is  indicated 
to  be  done  only  in  Cfycle  N. 

If  you  have  initiated  or  performed  an  assessment  prior  to  establishing  the 
needed  foundation  (i.e.,  the  SC  or  PG),  refer  to  the  Build/Reinforce  Spon- 
sor^p  and  Fbundation  activity  for  guidance  on  establishing  these  groups. 


Start  Criteria 

Use  the  following  fypes  of  information  and/or  working  knovdedge  as 
inputs  to  this  activity: 

•  Selected  assessment  method 

•  Internal  environment  information,  including  organizaticMial  and  {voject 
polides  and  procedures,  and  process  definition  documents 

•  Any  historical  process  improvement  information 


Tasks 


In  this  activity,  you  will  gain  an  understanding  of  the  software  processes 
your  organization  currently  practices. 
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1.  Asscss/UBderstand  liibar  Oisanizatioii’s  Ciirreat  Process.  Evoy  software 
oiganBatioii,  r^aicDess  of  see  or  maturity,  has  a  process  for  developing  and 
maintaining  s(^tware.Brfcyeuiyrovemeols  can  be  made,  you  must  haro  a  dear 
understanding  of  your  current  software  process. 

If  your  process  inqxofvement  program  is  ^  beaming  ex' needs  reiiivigoratiit& 
it  is  best  to  have  an  extonal  vnrdor  lead  the  assessmoit  This  provides  the 
following  benefits: 

•  Independent  view  from  someone  who  is  unbiased  and  an  expert  in  the 
chosen  assessment  method 

•  Guidance  and  insight  into  how  to  implement  the  assessment  method, 
including  planning 

•  Demonstrated  commitment  since  the  sponsor  is  willing  to  invest 
resources  (time,  money,  people) 

Formal  assessments  are  relatively  expensive  and  should  be  conducted 
when  you  expect  findings  and  recommendations  to  be  formulated  that  are 
significantly  different  from  the  status  quo. 

If  your  process  improvement  program  is  in  full  swing,  you  may  not  want 
to  expend  the  level  of  rerources  required  by  a  formal  assessment  Instead, 
you  may  be  able  to  compare  the  recommendations  from  the  previous  as¬ 
sessment  to  the  improvements  that  have  been  implemented  and  ascertain, 
objectively,  what  areas  need  to  be  worked  on  next.  Be  aware  of  any  orga¬ 
nizational  or  process  changes  that  have  occurred  in  the  time  period  since 
the  formal  assessment  so  that  you  can  determine  if  your  conclusions  are 
still  valid. 

Regardless  of  the  degree  of  formality  you  choose,  you  may  want  to  initiate 
a  new  spiral  focused  specifically  on  implementing  a  process  assessment. 

Refer  to  i^)pendix  B  for  a  description  of  three  different  process  assessment 
methods. 

This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Execute  the  steps  in  the  method  that  you  selected  to  assess  and  understand 
your  process.  Develop  a  set  of  findings,  based  on  the  information  gathered. 
If  several  findings  are  similar  in  nature,  you  may  want  to  group  them  into 
one  category  with  several  sub-findings.  This  task  ^ically  concludes  with 
a  short  presentation  to  your  sponsor  on  the  findings  of  the  assessment. 

Refer  to  Appendix  C  for  an  annotated  outline  of  a  findings  presentation. 
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2.  Identify  Reconunoidations  for  Improvement.  Base  the  recommendations 
both  on  the  findings  firom  an  assessnwnt  or  appraisal  and  (»  any  othm’ 
organizational  issues  that  you  feel  are  in^rative  to  inqxove. 

Cycle  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cyde  N  Categorize  the  reoommendatkms  into  logical  areas  for  inqirovement  \Mthin 

each  one  of  these  major  areas,  identify  the  focus  d  improvement  Rm’  exam¬ 
ple,  if  an  assessment  found  tfiat  no  documented  practices  existed  for  project 
planning,  the  focus  for  the  project  [banning  area  would  be  to  develop  policies 
and  procedures  for  {x-oject  {banning.  If  policies  and  procedures  were  found 
to  exist  the  focus  might  be  on  training  and  instituticxializing  those  project 
{danning  practices. 


3.  Develop  a  Findings  and  Recommendations  Report  Once  you  have 
developed  findings  and  recommendations,  you  need  to  capture  this 
information  in  a  report.  This  task,  along  with  Ihsk  2,  should  be  completed 
within  four  to  six  weeks  after  the  conclusion  of  Ihsk  1. 


Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Develop  a  report  to  be  presented  to  your  sponsors.  You  do  not  need  to 
present  great  detail  in  this  report,  since  it  will  be  incorporated  into  and 
expanded  in  the  action  plan  produced  in  Step  3,  Plan  Improvements. 

Refer  to  Appendix  D  for  an  annotated  template  of  a  findings  and 
recommendations  report. 


4.  Present  the  Recommendations.  The  recommendations  presentation 
supports  the  findings  and  recommendations  report  and  should  be  con¬ 
ducted  soon  after  the  completion  of  the  report  (Iksk  3).  Include  the  find¬ 
ings  in  your  presentation  to  provide  context  for  eadi  recommendation  and 
to  jog  memories. 


Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Present  the  recommendations  tc  your  sponsors.  Encourage  your  sponsors 

to  invite  all  the  stakeholders  in  the  organization.  This  will  demonstrate  to 
the  stakeholders  that  the  sponsors  are  serious  about  process  improvement 
and  that  they  do  not  want  to  keep  anything  hidden. 


Refer  to  Appendix  E  for  an  annotated  outline  of  a  recommendations 
presentation. 
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Measures 
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In  order  to  quantify  resources  spent  on  jn^ocess  imjx’ovement,  and  to 

improve  the  process  improvement  process  itself,  collect  the  following 

measures: 

•  Time  and  effort  spent  on  {banning  for  a  process  assessment  or  other 
a{^raisal 

•  Time  and  effort  spent  on  implementing  an  assessment  or  other  apfxaisal 

•  Number  of  findings  and  recommendations 

•  Time  and  effort  spent  develqsing  the  findings  and  recommendations 
report 

•  Size  of  the  findings  and  recommendations  report  (i.e^  number  of  pages) 

•  Quality  of  the  findings  and  recommendations  report 

•  Costs  incurred  for  an  external  consultant  to  conduct  a  fX'ocess  assessment 

•  Costs  incurred  for  any  tools  used  to  support  an  assessment  or  other 
appraisal  of  your  process 


Stop  Criteria 


This  activity  is  complete  when: 

•  You  have  prepared  a  description  of  the  findings  that  were  derived  from 
an  assessment  or  appraisal  of  your  organization’s  processes 

•  You  have  prepared  a  description  of  recommendations  made  by  the 
assessors  to  address  the  assessment  findings 
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4.4  REVIEW  CONTEXT 


This  activity  begins  in  Step  1,  Understand  Context. 


Your  objective  in  this  activity  is  to  adiieve  agreement  on  the  current  state 
of  the  organization,  as  you  understand  it.  Consensus  should  be  reached  on 
the  objectives,  alternatives,  and  constraints  for  both  the  process 
improvement  program  and  the  current  cycle,  as  well  as  on  the  findings  and 
recommendations  from  a  software  process  assessment. 


Start  Criteria 


Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Alternative  strategies  for  the  process  improvement  program  and  for 
the  cycle 

•  Understanding  of  the  current  process  to  be  changed,  including  findings 
and  recommendations 

•  Understanding  of  who  are  the  stakeholders  for  this  review 


Tasks 


In  this  activity,  you  will  obtain  agreement  from  stakeholders  other  than  the 
sponsors  on  the  current  organizational  context,  including  any  findings  and 
recommendations,  receive  approval  from  the  sponsors  on  the  alternative 
strategies,  and  publicize  the  commitment  to  continue  to  the  next  step. 

1.  Obtain  Agreement  From  Change  Agents,  Champions,  and  Process 
Users.  Seek  agreement  first  from  all  stakeholders  other  than  the  sponsors. 
What  may  change  from  (tycle  to  cycle  for  this  task  are  the  people  who  are 
the  change  agents,  champions,  and  process  users. 
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4.Birthliifct  BMdme:  UadentaadCoaial 


Cycle  1  You  will  seek  agreement  on  your  understanding  of  the  organization’s 
climate  and  readiness  for  change  and  the  strategy  to  improve  the  process. 
While  it  is  better  to  have  strong  suj^rt  early  on,  remember  that  some 
people  will  resist  change,  especially  when  there  is  no  sponsor.  Do  not  get 
hung  up  in  trying  to  get  everyone’s  full  agreement.  Identify  those  vidio  do 
agree;  they  can  become  champions  later  in  the  process.  Fay  attention  to  the 
grumbling  you  hear;  the  causes  may  become  barriers  (risks)  in  Cycle  2. 

Cycle  2  Again,  you  will  seek  agreement  on  your  understanding  of  the 
organization’s  climate  and  readiness  for  change  and  the  strategy  to 
improve  the  process.  This  information  may  have  changed  from  Cycle  1, 
based  on  discussions  with  potential  sponsors,  'fypically,  the  community 
that  you  include  in  this  review  will  be  larger  than  that  in  Cycle  1. 

Cycle  N  In  later  cycles,  you  will  seek  agreement  on  the  cycle  strategy  and  the 
findings  and  recommendations  that  result  from  an  assessment  or  appraisal 
of  your  processes. 

2.  Obtain  Approval  from  Sponsors.  After  you  have  buy-in  from 
champions,  change  agents,  and  process  users,  present  your 
recommendations  to  the  sponsors  for  approval.  Your  presentation  should 
include: 

•  Description  of  the  program  and  cycle  objectives,  alternatives,  and 
constraints 

•  Your  recommendation(s)  for  the  next  steps  (typically  execution  of  the 
remaining  cycle  steps) 

•  Your  rationale  for  the  recommendation 

•  Impact  antidpated  of  the  recommendation  on  the  organization, 
espedally  the  impaa  on  eadi  sponsor’s  group 

•  Estimated  cost  and  time  frame  for  the  recommendation 

Depending  on  your  situation,  you  may  dedde  to  stagger  the  presentations, 
addressing  first  those  sponsors  who  are  more  supportive,  in  order  to  build 
a  stronger  case  for  those  sponsors  who  are  less  supportive. 

You  may  have  to  go  through  several  iterations  of  your  presentation  to 
management  before  you  get  a  final  decision  to  go  ahead  with  the  imple¬ 
mentation.  If  so,  return  as  necessary  to  any  task  in  this  activity  or  in  the 
Analyze  and  Resolve  Risks  or  Select  Strategy  activities  in  order  to  secure 
the  decision  to  proceed. 
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4.  Est^lish  a  Baseline:  Understand  Context 

iBS 

Cycle  I  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  2  Review  the  process  improvement  program  strategy  with  your  authorizing 

and  reinforcing  sponsors.  You  may  need  to  modify  the  program  strata, 
based  on  any  changes  recommended  by  the  sponsors. 

Cycle  N  In  later  cycles,  you  will  seek  approval  on  the  (yde  strategy  from  your 
authorizing  and  reinforcing  sponsors. 


$ 


5P> 


3.  Publicize  Commitment.  After  approving  the  reoommendation(s),  the 
sponsors  need  to  publidze  their  support  and  commitment  throughout 
their  organizations  to  keep  everybody  informed,  to  reinforce  the  impor¬ 
tance  of  process  improvement,  and  to  help  prepare  everybody  for  the 
changes  ahead. 


Cycle  1  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  2...N  Assist  the  sponsors  with  publicizing  commitment  to  process  improvement. 
Use  the  influence  strategy  created  in  Step  1,  Understand  Context. 


Measures 


In  order  to  quantify  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  Time  and  effort  spent  reviewing  the  current  organizational  context 
with  change  agents,  champions,  and  process  users 

•  Number  of  persons  interacted  with  during  the  review 

•  Time  and  effort  spent  developing  a  management  presentation 

•  Size  of  the  management  presentation  (e.g.,  number  of  charts) 

•  Quality  of  the  management  presentation 

•  Time  and  effort  spent  meeting  with  sponsors 

•  Number  of  presentations  to  and  meetings  held  with  sponsors 
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Time  and  effort  spent  publicizing  commitment 


•  Number  of  persons  to  ^^m  and  i^aoes  \^ere  omnmitmmt  was 
publitued 


StopCriteiua 

This  acdviQr  is  oomi^ete  when  you  have  achieved  both  agreement  (»)  the 
{X'ogram  and  (^e  context  from  all  identified  stakeholders  and  commitment 
from  the  sponsor  to  proceed. 
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4.  Estabfish  «  Baseline:  Understand  Context 


This  page  intentionaUy  left  blank. 
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5.  LOOK  BEFORE  YOU  LEAP:  ANALYZE  RISKS 
AND  SELECT  STRATEGY 


>Msdoin  consists  in  being  able  to  distinguish  among  dangers  and  make  a  dioice  of  the  least  harmful. 

Nicoolo  Machiavelli,  The  Prince 


Section  Objectives 

1.  ^wide  guidance  for 
anafyzing  and  resolving 
risks  associated  with 
process  improvement 

2.  Provide  guidance  for 
selecting  a  strategy  for 
process  improvement 


After  identifying  the  context  in  which  you  are  performing  the  process 
improvement,  you  first  perform  risk  analysis  to  help  identify,  address,  and 
eliminate  risk  items  before  they  become  threats  to  the  success  of  process 
improvement  activities,  and  then  take  action  to  minimize  or  eliminate 
them.  Based  on  your  risk  analysis  and  mitigation,  you  will  select  an 
improvement  strategy  for  the  remainder  of  the  cycle.  This  section  provides 
guidance  for  the  activities  shown  in  Figure  5-1. 


Figure  5-1.  Analyze  Risks  and  Select  Strategy  Activities 


5.  Loolc  Before  You  Leap:  AnilyaeR«ki«iid  Select  Stnuegy 


5.1  ANALYZE  AND  RESOLVE  RISKS 


This  activity  begins  in  Step  2,  Analyze  Risks  and  Select  Strategy. 


Overview 


The  objective  of  this  activity  is  to  identify  and  resolve  the  risks  associated 
with  the  identified  alternatives  for  the  process  improvement  program 
strategy  and  the  cycle  strategy.  Pro^am  risks  occur  at  the  strategic  level; 
they  are  analyzed  in  the  first  two  cycles  and  then  reviewed  in  subsequent 
cycles.  Cycle  risks  occur  at  the  tactical,  or  implementation,  level  and  are 
analyzed  in  each  cycle. 

A  risk  is  the  potential  for  incurring  undesirable  results.  Risk  analysis  is  a 
proactive  management  approach  that  first  focuses  on  what  can  go  wrong 
and  then  attempts  to  keep  it  from  occurring.  In  this  activity,  you  will  con¬ 
centrate  on  the  frctors,  or  risks,  that  may  prevent  prc^am  or  cycle  success. 
You  will  specifically  address  these  risks  in  this  step  by  evaluating  the  strate¬ 
gies  defined  in  terms  of  any  identified  constraints.  The  primary  result  of 
this  evaluation  is  a  quantified  list  of  risks  for  the  program  and/or  the  cur¬ 
rent  cycle.  After  identifying  and  quantifying  risks,  you  will  evaluate  possi¬ 
ble  risk  mitigation  strategies  and  commit,  plan,  and  execute  one  of  those 
strategies. 

Create  an  electronic  or  paper  trail  (e.g.,  memos  to  a  file)  for  this  activity. 
Since  you  will  screen  and  evaluate  a  range  of  strategies,  documentation 
will  help  you,  at  a  later  date,  justify  and/or  explain  your  reasons  for  your 
decisions.  This  document  will  be  referred  to  as  your  risk  management  plan. 
Refer  to  Appendix  F  for  an  annotated  template  of  a  risk  management  plan. 

The  risk  management  plan  should  be  regarded  as  an  evolutionary 
document.  You  will  document  and  mitigate  as  many  risks  as  you  can  during 
this  activity,  but  that  does  not  preclude  risks  from  being  identified  later  in 
the  cycle,  especially  during  Step  3,  Plan  Improvements,  and  Step  4, 
Implement  Improvements. 

Process  Engineering  With  the  Evolutionary  Spiral  Process  Model  (Software 
Productivity  Consortium  1993b)  provides  detailed  information  on  per¬ 
forming  risk  analysis  and  was  the  primary  source  for  guidance  for  this  ac¬ 
tivity.  Additional  guidance  for  supporting  risk  analysis  can  be  found  in 
Charette  (1989)  and  the  U.S.  Air  Force  (1988). 
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Start  Criteria 


Use  the  following  types  of  information  and/or  working  knowdedge  as 
inputs  to  this  activiQr. 

•  Defined  and  approved  objectives  and  constraints  for  the  process 
improvement  program  and  the  cycle  that  all  stakeholders  support 

•  Alternative  program  and/or  (^cle  strategies  that  need  to  be  analyzed 

•  Any  previous  risk  management  plans,  from  either  a  process 
improvement  or  another  organizational  initiative 

•  Any  historical  process  improvement  data 


Tasks 


In  this  activity,  you  will  identify,  analyze,  and  evaluate  risks  to  your 
program  and  current  cycle  objectives  and  conduct  a  review  of  these  results 
with  the  stakeholders.  Then  you  will  plan  and  execute  risk  mitigation 
strategies. 

1.  Identify  and  Analyze  Risks.  Identify  all  risks  to  your  current  objectives, 
defined  in  the  previous  step,  and  understand  the  relationship  between  the 
risks  to  your  objectives  and  the  alternatives  you  defined. 

For  each  risk  you  identify,  estimate  the  following: 

•  Probability  of  Occurrence.  The  probability  of  the  event  (risk)  occurring. 
If  there  is  no  chance,  then  the  event  is  not  a  risk. 

•  Cost  of  Occurrence,  The  unfavorable  outcome  (consequences)  if  the 
event  (risk)  were  to  occur.  The  outcome  must  have  a  direct  impact  on 
your  objectives.  If  there  is  no  gain  or  loss,  then  the  event  is  not  a  risk. 

•  Frequency  of  Occurrence.  The  rate  at  which  the  event  could  occur  over 
time.  If  the  cost  and  probability  of  occurrence  are  constant,  then  the 
frequency  of  occurrence  affects  the  amount  of  risk  exposure.  For  ex¬ 
ample,  an  activity  that  is  performed  incorrectly  once  a  week  has  an  im¬ 
pact  different  from  that  of  an  activity  that  is  performed  incorrectly 
once  a  year. 

•  Other  Choices  That  Exist.  The  existence  of  other  options.  If  no  choices 
exist,  then  the  outcome  cannot  be  prevented,  and  the  event  must  be 
viewed  as  a  constraint. 
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S.  Look  Before  You  Leap:  Analyze  Risks  and  Select  Strata 

Cycle  I  In  the  first  (^de,  you  look  at  the  risks  assodated  with  the  alternative 
process  improvement  strategies.  Examine  your  prc^am  strategies  in  light 
of  the  objectives  and  constraints  that  you  identified  in  Step  1,  Understand 
Context.  Look  for  potential  inconsistendes  or  conflicts,  and  estimate  the 
potential  consequences  (loss  or  gain)  and  the  likelihood  of  eadi  occurring. 
Document  these  risks  in  your  draft  risk  management  {dan. 

The  common  barriers  (risks)  to  a  process  improvement  program  are 
described  in  the  Software  Engineering  Prot^ss  Group  Wor^hop  Survey 
conducted  by  Implementation  Management  Assodates,  SEI,  and  Masters 
Systems  (1992); 

•  Pressure  to  Meet  Schedules.  During  chaotic  times,  management  often 
has  neither  the  disdpline  to  adhere  to  a  process  nor  the  interest  to  initi¬ 
ate  process  improvement  in  the  organization.  The  organization  is 
faced  with  the  “chicken  and  egg”  problem:  Management  and  staff  want 
to  improve  the  process,  but  cannot  get  away  from  schedule  pressures 
long  enough  to  improve  the  process. 

•  Misplaced  or  Inappropriate  Rewards.  Historically,  software  engineers 
are  rewarded  for  “fire-fighting”  activities.  Improving  the  process  fo¬ 
cuses  on  establishing  “fire-prevention”  activities  so  that  there  are  few¬ 
er  fires  to  put  out  later.  In  most  organizations,  though,  the  reward  and 
recognition  systems  are  not  aligned  to  motivate  the  desired  behavior, 
i.e.,  fire  prevention. 

•  Lack  of  Commitment  of Middle  Matwgers.  Middle  management  may  be 
uncommitted  to  process  improvement  for  several  reasons:  They  are 
unaware  of  the  importance  of  process  improvement  to  their  manage¬ 
ment  (authorizing  sponsor);  they  and  their  staff  do  not  directly  report 
to  the  authorizing  sponsor;  or  they  are  not  convinced  of  the  need  for 
process  improvement. 

•  Lack  of  Key  Resources.  This  barrier  is  similar  to  sdiedule  pressure  in  that 
management  is  committed  to  process  improvement,  but  does  not  have 
enough  resources  (people,  mon^,  or  time)  to  follow  through.  It  is  best 
for  management  both  to  understand  the  level  of  resources  required  be¬ 
fore  committing  to  process  improvement  and  to  sdiedule  those  resources 
into  the  plan.  Tbo  often,  process  improvement  activities  are  left  out  of 
planning  and  scheduling  activities. 

•  Lackof Clear  Expectations.  Most  stakeholders  typically  do  not  have  agood 
understanding  of  what  management  expects  of  them  and  of  the  implica¬ 
tions  of  process  improvement.  Without  dear  expectations,  thqr  are  firee 
to  believe  whatever  they  perceive  to  be  the  expectations — which  are 
usually  negative. 
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5.  Loot  Below  YwLMMcAMtwlUrtnadSdKHwag 


•  OOtar  Major  Changes.  Major  changes  cause  organizational  stress  and 
can  affect  an  organization’s  ability  to  handle  yet  another  major  change, 
such  as  process  impM’ovement. 

Process  improvement  i^ogram  failure  incurs  both  shmt-  and  long-term  costs. 
The  costs  associated  with  this  risk  of  failure,  adapted  frmn  Imfdementatimi 
Management  Associates  (1992),  include: 

•  Short-Term  Costs.  You  directly  impact  the  organization  by  wastiiig 
resources  (money,  time,  and  people)  and  failing  to  adiieve  a  stated 
business  objective.  Indirectly,  the  morale  of  your  staff  suffers  because 
they  may  have  invested  their  own  time  and  energy  into  the  process 
improvement  program. 

•  Loi^-Term  Costs.  A  direct  consequence  of  failure  of  a  process  improve¬ 
ment  program  is  that  the  organization’s  long-term  strategies  are  not 
accomplished.  Indirectly,  the  staff  may  have  reduced  confidence  in 
management’s  leadership  ability  and  may  increase  their  resistance  to 
the  next  change,  thereby  making  it  more  difficult  to  adiieve  success 
with  the  next  change. 

Cycle  2  In  this  cyde,  look  at  the  risks  associated  with  the  alternative  process  assessment 

methods  and  risks  associated  with  organizational  issues,  such  as  readiness, 
culture,  and  stress.  Document  these  rides  in  your  draft  ride  management  plan. 

Potential  organizational  risk':  uiat  may  be  present  in  this  <^le  include  the 
following  are: 

•  Commitment  has  not  been  cascaded  from  the  authorizmg  sponsor 
through  all  reinforcing  sponsors. 

•  The  organization’s  reward  system  is  not  aligned  with  the  behaviors 
needed  to  get  to  the  desired  state. 

•  Rewards  to  the  change  agents  for  successful  process  improvements  are 
unclear. 

•  Process  users  do  not  feel  a  sense  of  urgency  for  process  improvement, 
or  the  desired  state  is  not  compelling  enough  for  them  to  make  the  re¬ 
quired  changes. 

•  The  experiences  and  skills  of  the  PG  members  may  be  inadequate  or 
unsuitably  matched  to  the  current  Qrcle  focus. 

•  The  SC  may  be  ineffective  as  a  team. 

Cycle  N  In  subsequent  cycles,  you  will  both  identify  risks  assodated  with  the 
current  cycle  and  review  the  pr(x;ess  improvement  program  risks  defined 
in  earlier  cycles  to  see  if  any  changes  are  needed,  based  on  the  results  of 
previous  cycles.  Document  these  risks  in  your  draft  risk  management  plan. 


5-5 


S.  Look  Before  You  Leap:  Analyze  Risks  and  Select  Strategy 

Examples  of  cycle  risks  you  may  encounter  include  the  following: 

•  The  experiences  and  skills  of  the  PG  and  PAT  members  may  be  either 
inadequate  or  unsuitably  matched  to  the  current  t^cle  focus. 


•  Based  on  progress  made  in  previous  cycles,  you  might  find  that 
implementation  and  institutionalization  are  not  moving  quickly 
enough  to  enable  the  organization  to  see  benefits.  It  is  very  hard  for 
management  to  continue  to  support  improvement  efforts  without 
seeing  any  progress  made,  lly  to  mitigate  this  risk  by  planning 
short-term  activities  (incremental  progress)  into  the  (^de,  if  possible. 


Cycle 


•  Based  on  progress  made  in  previous  cydes,  you  might  find  that  the 
improvements  are  not  mating  the  expected  impact.  You  might 
mitigate  this  risk  by  looting  at  your  cycle  objectives  to  see  if  you  are 
focusing  on  the  proper  areas. 

2.  Review  Risk  Analysis.  This  task  provides  an  opportunity  for  team  review 
and  comment  on  the  risk  identification  and  analysis  results.  This  review  also 
provides  an  opportunity  for  additional  risks  to  be  identified.  It  may  be  neces¬ 
sary  to  repeat  the  previous  task  until  consensus  occurs  on  the  identification 
and  analysis  of  risks. 

Have  all  stakeholders  for  this  (tycle  review  the  draft  risk  management  plan 
that  includes  these  results.  Incorporate  their  comments  as  needed. 

3.  Evaluate  and  Plan  Risk  Mitigation.  During  this  task  you  both  identify 
strategies  to  reduce  the  cost  and/or  probability  of  risk  occurrence  to  an  ac¬ 
ceptable  level,  and  document  the  estimated  cost  and  schedule  for  each  risk 
mitigation  strategy.  Risk  mitigation  strategies  generally  fall  into  one  or 
more  of  the  following  categories: 


•  Risk  Reduction.  Reduce  either  the  likelihood  of  a  risk  occurring  and/or 
the  magnitude  of  the  risk.  For  example,  the  risk  of  a  late  delivery  may 
be  reduced  by  extending  the  schedule. 

•  Risk  Protection.  Lessen  the  impact  of  a  risk.  Insurance  is  an  example  of 
risk  protection. 

•  Risk  TYanrfer.  Reallocate  risks  to  areas  better  able  to  handle  them. 

•  Itisk  Contingency  Fimd.  Establishes  a  reserve  of  resources  that  is  set 
aside  to  compensate  for  any  unplanned  situations.  The  most  common 
reserved  resources  are  time  and  money. 

•  Ksk  Acceptance.  Accept  the  consequences  when  there  may  be  no 
cost-effective  means  to  avert  a  risk. 
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It  is  possible  for  risk  mitigation  strategies  to  introduce  new  risks  that 
detract  from  the  anticipated  benefits.  For  examine,  extending  a  sdiedule 
to  reduce  a  delivery  date  risk  may  introduce  a  risk  of  contract 
noncompliance.  Therefore,  the  impact  of  the  risk  mitigation  strat^es 
must  also  be  identified,  analyzed,  and  evaluated. 

For  each  of  the  alternate  strategies,  answer  the  following  questions: 

•  What  does  the  strategy  entail? 

•  Is  the  strategy  feasible? 

•  Does  the  strategy  seem  effective  to  reduce  risk  to  an  acceptable  level? 

•  Will  the  strategy  negatively  impact  another  risk  or  objective? 

•  What  is  the  potential  impact  of  new  risks,  if  any,  introduced  by  the 
strategy? 

•  Does  the  strategy  support  (^cle  objectives? 

•  Are  the  tactics  and  means  for  implementing  the  strategy  consistent 
with  cycle  constraints? 

•  Is  the  strategy  cost-effective,  or  will  it  use  more  resources  than  can 
reasonably  be  expected  to  be  saved  through  the  risk  mitigation? 

Cycle  /..  JV  Document  the  risk  mitigation  strategies  in  your  draft  risk  management 
plan.  This  plan  is  enhanced  later  in  the  cycle.  For  each  mitigation  strategy, 
include: 

•  DesCTiption  of  the  mitigation  strategy 

•  Specific  risk(s)  that  you  will  mitigate 

•  Work  breakdown  structure  (WBS)  that  lists  the  individual  tasks  that 
you  need  to  accomplish,  including  an  estimate  of  how  long  it  will  take 
to  complete  each  task,  when  the  task  is  to  begin,  and  an  estimate  of  the 
resources  required 

•  Any  constraints  that  may  affect  this  mitigation  strategy 

•  Criteria  for  success  (i.e.,  i»hen  you  will  consider  the  risk[sj  to  be 
mitigated) 


Refer  to  Appendix  F  for  an  annotated  template  of  a  risk  management  plan. 


S.  Look  BeCore  You  Leap:  Analyze  Risks  and  Selea  Strategy 

4.  Cooumt  to  the  Risk  ManageiiicBt  Phui.  Hus  task  is  a  mediaiusm  for 
formal^  briefo^  aU  stakduidos  on  the  oootents  of  the  draft  risk  managonoit 
plan  and  the  risk  mitigation  strat^ies. 


Cycle  l..Ii  Obtain  consensus  and  commitment  from  the  stakeholders  for  this  cycle  to 

the  risk  mitigation  strategies.  If  consensus  is  not  readied  or  commitment 
not  secured,  then  the  risk  activities  in  Step  2  may  need  to  be  repeated. 


5.  Execute  Risk  Mam^ement  Plan.  In  diis  tasi^  you  execute  the  risk  mit^atkm 
activities  (xitlined  in  the  draft  risk  management  i^an,  devdoped  in  the  previous 
task.  Depending  on  die  risk  initiation  acdvides,  you  may  need  to  imolve  all 
stakeholders. 


Cycle  7..  JV  Perform  the  risk  mitigation  activities  as  outlined  in  the  risk  management 
plan.  For  each  risk  mitigation  activity,  you  may  want  to  either  complete 
one  or  more  cycles,  or  spin  off  another  spiral. 


Measures 


In  order  to  quantify  resources  spent  on  process  improvement,  and  to  improve 
the  process  improvement  process  itself  collect  the  following  measures: 

•  Hme  and  effort  spent  identifying  and  analyzing  risks 

•  Number  of  risks  identified  and  analyzed 

•  Time  and  effort  spent  reviewing  risk  analysis 

•  Number  of  persons  involved  in  reviewing  risk  analysis 

•  Hme  and  effort  spent  evaluating  and  planning  risk  mitigation  strategies 

•  Number  of  risk  mitigation  strategies 

•  Time  and  effort  spent  executing  risk  mitigation  strategies 

•  Number  of  persons  involved  in  executing  risk  mitigation  strategies 

•  Time  and  effort  spent  developing  the  risk  management  plan 

•  Size  of  the  risk  management  plan  (e.g.,  number  of  pages) 

•  Quality  of  the  risk  management  plan 
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SiopCriteru 


This  activity  is  complete  when  you  have  identified,  analyzed,  and  mitigated 
any  risks  related  to  the  alternative  process  im[vovement  strategies  and  the 
alternative  <^le  strategies. 


I 

i 
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5.  Look  Befofc  You  Lop:  Analyze  Risks  nd  Select  Strategy 


5.2  SELECT  IMPROVEMENT  STRATEGY 


This  activity  begins  in  Step  2,  Analyze  Risks  and  Select  Strategy. 


Overview 


The  objective  of  this  activity  is  to  select  one  of  the  alternative  strategies 
identified  in  Step  1,  based  on  your  program  and  cycle  objectives  and  con¬ 
straints,  your  understanding  of  the  process  to  be  improved,  and  on  your 
analysis  of  the  risks  associated  with  each  of  the  identified  alternatives. 


Start  Criteria 


Use  the  following  types  of  information  and/or  working  knowledge  as 

inputs  to  this  activity: 

•  Defined  and  approved  objectives  and  constraints  for  the  software 
process  improvement  program  and  the  (^de  that  are  supported  by  all 
stakeholders 

•  Alternative  program  and/or  tyde  strategies 

•  Results  from  executing  the  risk  management  plan,  including  risk 
mitigation 


Cycle  1,2 


You  will  select  the  reconunended  program  and/or  cycle  strategy. 

1.  Select  a  Process  Improvement  Program  and/or  Cyde  Strategy.  Based 
on  your  approved  objectives  and  constraints  for  the  program  and  t^le,  the 
alternative  strategies  identified,  and  the  risk  analysis  and  mitigation 
conducted  in  the  previous  activity,  you  select  a  recommended  strategy  for 
the  process  improvement  program  and  the  cycle.  You  also  generate 
documentation  as  to  why  you  selected  one  strategy  over  the  others. 

For  these  two  (ycles,  review  the  process  improvement  prt^am  strategies 
and  results  of  any  risk  mitigation  with  other  champions  and  change  agents 
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5.  Look  Befixe  Leaoc  Aaalm  Rkki  Sdad  StoaMcr 

who  are  assisttng  you  with  program  initiation.  Select  a  strata  for  the 
process  imjn'ovement  {vogram.  This  strategy  may  be  nuxlified  in  Cyde  2 
to  incorporate  comments  from  the  stakeholders  (e.g.,  management  may 
not  support  and  sponsor  the  program  without  certain  dtanges  made  to  the 
strategy). 

Cyde  N  In  subsequent  cycles,  select  a  strategy  for  the  current  cycle.  If  the  program 

strategy  has  changed  because  of  progress  made  in  previous  c^les,  or  dif¬ 
ferent  alternative  program  strategies  have  been  identified  and  analyzed, 
then  you  may  need  to  select  a  new  program  strategy. 


Measures 

In  order  to  quantify  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  Time  and  effort  spent  reviewing  the  program/cycle  strategy 

•  Number  of  persons  involved  in  reviewing  the  program/cycle  strategy 

•  Time  and  effort  spent  selecting  the  program/cycle  strategy 

•  Time  and  effort  spent  changing  the  program/cycle  strategy 


Stop  Criteria 


This  activity  is  complete  when  you  have  arrived  at  the  recommended 
process  improvement  program  and/or  cycle  strategy,  and  have  prepared 
documentation  as  to  why  this  strate^  is  recommended  over  the  others. 
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53  COMMIT  TO  STRATEGY 


This  activity  begins  in  Step  2,  Analyze  Risks  and  Select  Strategy. 


Overview 


Your  objective  in  this  activity  is  to  seek  commitment  from  all  stakeholders 
to  the  strategy  for  the  process  improvement  program  and/or  the  cycle.  A 
key  part  of  this  activity  is  for  the  sponsors  to  publidze  the  recommendation 
and  commitment  throughout  the  organization.  Ample  opportunity  should 
be  provided  for  the  stakeholders  to  review  and  comment  on  your  recom¬ 
mendations.  Based  on  the  review  results,  you  may  determine  that  you  need 
to  revise  your  recommendations. 


Start  Criteru 


Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Recommended  strategy  for  the  process  improvement  program  and/or 
the  cycle,  along  with  documentation  to  support  this  selection 

•  Understanding  of  who  are  the  stakeholders  for  this  activity 


Tasks 


You  need  to  obtain  approval  from  the  identified  stakeholders  on  the 
selected  program  and/or  cyrcle  strategy. 

1.  Obtain  Agreement  From  Change  Agents,  Champions,  and  Process 
Users.  Seek  agreement  first  from  identified  stakeholders  other  than  the 
sponsors.  The  sponsors  will  approve  your  selection  with  less  resistance 
when  there  is  buy-in  from  the  other  players  involved.  Since  the  champions 
and  change  agents  helped  identify  the  selected  strategies,  focus  on  getting 
the  process  users  and  any  other  champions  and  change  agents  to  review 
and  agree  on  the  selection.  You  may  need  to  go  through  several  iterations 
of  the  review  process  before  an  agreement  is  reached. 
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5.  Look  Before  You 


Leupe  AaelyicRBlBeudSetoSlrMep 


Q^le  1  You  will  seek  agreement  on  the  process  improvement  program  strategy  in 

the  first  cycle.  While  it  is  better  to  have  strong  support  early  on,  remember 
that  some  stakeholders  resist  change,  especially  when  there  is  no  sponsor. 
Do  not  get  hung  up  in  trying  to  get  everyone’s  full  agreement.  Identify 
those  stakeholders  who  do  agree;  they  can  become  champions  later  in  the 
process.  Pay  attention  to  the  grumbling  you  hear;  the  causes  may  become 
barriers  (risks)  in  Cycle  2. 

Cycle  2  Again,  you  will  seek  agreement  on  the  process  improvement  program 
strategy,  though  you  may  modify  the  program  strategy  based  on  any 
recommended  changes. 

Cycle  N  In  later  cycles,  you  will  seek  agreement  on  the  cycle  strategy,  which  is  how 

the  organization  will  implement  improvements  based  on  assessment 
recommendations. 


2.  Obtain  Approval  From  Sponsors.  After  you  have  buy-in  from  champions, 
change  agents,  and  process  users,  present  your  recommendations  to  the 
sponsors  for  approval.  Your  presentation  should  include: 

•  Description  of  the  recommendation 

•  Your  rationale  for  the  recommendation 

•  Anticipated  impact  of  the  recommendation  on  the  organization, 
especially  the  impact  on  each  sponsor’s  group 

•  Estimated  cost  and  time  frame  for  the  recommendation 


Cycle  1 
Cycle  2..JV 


Depending  on  your  situation,  you  may  decide  to  stagger  the  presentations, 
targeting  first  those  sponsors  who  are  more  supportive,  in  order  to  build 
a  stronger  case  for  those  sponsors  who  are  less  supportive. 

You  may  have  to  go  through  several  iterations  of  your  presentation  to 
management  before  you  get  a  final  decision  to  go  ahead  with  the  imple¬ 
mentation.  If  so,  return  as  necessary  to  any  task  in  this  activity  or  in  the 
Analyze  and  Resolve  Risks  or  Select  Improvement  Strategy  activities  in 
order  to  secure  the  decision  to  proceed. 

This  task  is  not  performed  until  adequate  sponsorship  is  established. 

In  later  cycles,  you  will  seek  approval  on  the  process  improvement 
program  strategy  and  the  qrcle  strategy. 

3.  Publicize  Commitment.  After  approving  the  recommendation,  the 
sponsors  need  to  publicize  their  support  and  commitment  throughout  their 
organizations  to  keep  everybody  iiiformed,  to  reinforce  the  importance  of 
process  improvement,  and  to  help  prepare  everybody  for  the  dianges  ahead. 
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Cycle  I  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  2..JN  Assist  the  sponsors  with  developing  a  communication  strategy  to  publicize 

commitment.  Use  the  influence  strategy  aeated  in  Step  1,  Understand 
Context. 


Measures 

In  order  to  quantify  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  Time  and  effort  spent  reviewing  the  program  and  cycle  strategies  with 
change  agents,  champions,  and  process  users 

•  Number  of  persons  interacted  with  during  the  review 

•  Time  and  effort  spent  developing  a  management  presentation 

•  Size  of  the  management  presentation  (e.g.,  number  of  charts) 

•  Quality  of  the  management  presentation 

•  Time  and  effort  spent  meeting  with  sponsors 

•  Number  of  presentations  to  and  meetings  held  with  sponsors 

•  Time  and  effort  spent  publicizing  commitment 

•  Number  of  persons  to  whom  and  places  where  commitment  was 
publicized 


Stop  Crtteru 

This  activity  is  complete  when: 

•  You  have  secured  commitment  from  all  stakeholders  on  the  program 
and/or  cycle  strategy 

•  The  sponsors  have  publicized  their  commitment  to  software  process 
improvement  to  the  organization 


6.  CHART  A  COURSE:  PLAN  IMPROVEMENTS 


Section  Objectives 

1.  Provide  guidance  for 
planning  process 
improvement  activities 

Z  Provide  guidance  for 
obtaining  commitment 
to  the  plan 


Focus  on  the  vital  few,  not  the  trivial  many. 

The  Pareto  Principle 

Commitment  to  and  implementation  of  process  improvements  cannot 
occur  without  a  well-thought-out  and  documented  plan.  This  section 
provides  guidance  for  the  activities  shown  in  Figure  6-1. 


Figure  6-1.  Plan  Iinprovements  Activities 
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6.  Chart «  Course:  Plan  Improwment. 


6.1  DEnNEAJPDATE  ACTION  PLAN 


This  activity  begins  in  Step  3,  Plan  Improvements. 


Overview 


Your  objective  in  this  activity  is  to  develop  an  action  plan  detailing  the 
implementation  of  the  chosen  strategy,  llie  plan  is  based  on  the  <^e 
objectives,  constraints,  and  strategy  defined  and  approved  in  the  previous 
steps  of  this  cycle.  The  sponsor  is  more  apt  to  provide  and  sustain 
commitment  when  the  implementation  details  are  well  understood. 

The  action  plan  activity  should  begin  within  four  to  six  weeks  after 
completion  of  the  Step  1,  Understand  Context,  activities  and  may  be 
performed  concurrently  with  Step  2,  Analyze  Risks  and  Select  Strategy.  A 
final  draft  of  the  action  plan  should  be  released  within  four  to  six  weeks 
after  commencing  this  activity.  The  longer  it  takes  either  to  commence 
planning  or  to  release  a  draft,  the  greater  the  chance  of  losing  momentum 
and  sponsorship. 

This  is  a  good  opportunity  for  you  to  increase  involvement  of  other 
stakeholders.  Increased  involvement  has  several  beneficial  effects;  the 
most  notable  is  surfacing  resistance.  Other  effects  are  decreased  stress  and 
greater  commitment  to  process  improvement.  By  involving  stakeholders 
with  the  planning  activity,  you  demonstrate  to  them  that  process 
improvement  is  not  being  done  to  them,  but  with  them. 

The  action  plan  should  be  regarded  as  an  evolutionary  document.  Do  not 
delay  its  release  while  searching  for  perfection!  As  you  gain  additional 
information  and  insights,  you  will  update  the  action  plan. 

The  action  plan  is  derived  from  a  broad  collaboration  of  all  stakeholders 
involved  in  process  improvement.  It  covers  the  following: 

•  Underlying  motivation  for  the  process  improvement  program 

•  Overall  strategy  of  the  organization  for  the  process  improvement 
program 

•  Major  areas  that  will  be  addressed  in  this  tycle 

•  Procedures  for  planning  improvement  activities  for  specific  projects  in 
each  major  area  of  improvement 
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6.  Chart  •  Comte:  PIm 


•  Groups  responsible  for  taking  action  in  each  major  area,  the  resources 
needed,  and  a  schedule 

The  action  plan  is  typically  a  set  of  plans  and  guidelines;  the  physical 
structure  is  up  to  you.  Figure  6-2  illustrates  a  logical  action  plan  structure 
(Fowler  and  Rifkin  1990). 


6-3 


6.  Chart  a  Course:  Plan  Improvements 


both  the  sc  and  PG.  Typically,  the  SC  is  responsible  for  developing  the 
strategic  plan. 

•  Tactical  Plan.  The  tactical  plans  describe  the  work  to  be  done  in  the 
current  cycle  by  the  SC,  the  PG,  and  the  PAR.  The  plan  for  each  PAT 
includes  a  charter  for  the  group,  describes  the  direction  of  work,  and 
includes  both  a  detailed  plan  for  improving  a  particular  process  area 
and  a  plan  for  developing  an  operational  template  for  applying  the 
process.  Once  the  PAT  has  made  improvements  to  a  process  and  devel¬ 
oped  an  operational  plan  template,  the  PAT  transfers  the  process  to 
one  or  more  projects.  The  information  gathered  during  this  transfer  is 
rolled  back  into  the  tactical  plan  for  future  use. 

•  Operational  Plan.  The  operational  plans  are  developed  by  a  PAT  for  a 
particular  project  that  is  focused  on  improving  a  particular  area.  The 
plan  details  the  activities  performed  to  transfer  a  particular  technology 
from  a  PAT  to  a  project.  For  a  complete  description  of  and  guidance 
for  technology  transfer,  refer  to  Using  New  Technologies:  A  Technology 
Transfer  Guidebook  (Software  Productivity  Consortium  1993e). 

A  template  for  an  action  plan  can  be  found  in  Appendix  G. 


Start  Criteru 

Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Approved  objectives,  constraints,  and  strategy  for  the  cycle 

•  Results  from  an  assessment,  or  information  and/or  knowledge  gained 
from  an  informal  appraisal 

•  Plans  from  any  previous  process  improvement  efforts 


Tasks 


You  will  manage  the  development  of  each  part  of  the  action  plan  and 
assemble  them  together  to  flnalize  the  action  plan. 

1.  Establish  a  PAT  for  Each  Major  Area  of  Improvement.  Based  on  the 
strategy  selected  in  Step  2,  either  a  PAT  or  the  PG  ultimately  is  responsible 
for  developing  improvements  in  a  particular  technical  area  and  for 
applying  them  to  one  or  more  projects. 
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APAT  is  comprised  oi  experienced  professionals  with  strong  bad^ounds 
and  interests  in  the  technical  area  under  improvement.  Each  project  that 
is  affected  by  the  technical  area  should  have  a  representative  on  the  PAT. 

Guidelines  for  selecting  the  PAT  leader  are: 

•  Senior  engineer  with  experience  in  the  technical  area  being  addressed 

•  Advocate  of  process  improvement 

•  Sdtware  IVocess  Assessment  (SB\)  participant— ideally  as  an  assessment 
team  member 

•  Project  management  skills 

•  Strong  team  building  and  team  dynamics  skills 

Generally,  the  PAT  leader  is  a  member  of  the  PG  during  the  life  span  of 
the  PAT.  It  is  the  responsibility  of  the  PAT  leader  to  coordinate  and  manage 
the  team’s  activities  and  to  report  progress  to  the  PG  and  the  SC. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  If  a  PAT  is  to  address  a  major  area  of  improvement,  identify  potential  team 

members,  including  a  Pv^  leader. 

After  the  team  has  been  established,  work  on  building  a  strong,  dynamic 
team  to  inaease  its  effectiveness.  This  group  will  work  closely  with  project 
staff  to  implement  process  improvement.  If  the  team  is  perceived  as 
ineffective  or  dysfunctional,  the  process  improvement  program  will  not  be 
perceived  positively. 

2.  Task  Eadi  PAT  to  Develop  a  Tactical  Plan.  You  are  now  at  the  point 
where  plans  to  improve  specific  areas  in  your  process  are  developed. 

The  primary  responsibilify  of  the  PAT  (which  may  be  the  PG)  is  to  develop 
a  tactical  plan  to  improve  a  specific  technical  area.  This  plan  covers  all  the 
activities  that  the  PAT  performs,  estimates  of  schedules  and  resources,  and 
other  relevant  information,  such  as  potential  risks.  The  PAT  typically  plans 
for  the  following  activities: 

•  Understanding  the  existing  process  (sometimes  called  the  “as-is”)  well 
enough  to  establish  requirements  of  the  process 

•  Documenting  the  new  process  (sometimes  called  the  “to-be”) 

•  Refer  to  the  Process  Definition  and  Modeling  Guidebook  (Software 
Productivity  Consortium  1992a)  for  more  information 
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•  Examining  industry  best  fx^actices  for  example,  attending 
conferences/workshops,  reading  conference  papers,  or  participating 
in  outside  working  groups 

•  Saeening  new  tedmologies 

•  Making  recommendations  on  new  tedmologies  to  pilot 

•  Planning,  in  coordination  with  the  PG,  for  tedmology  transition 

•  Organizing  workshops/seminars  to  disseminate  new  tedindpgy 
information 

•  Working  with  the  PG  to  design  operational  plans  for  projects 

•  Assisting  with  execution  and  evaluation  of  these  projects 

•  Preparing  templates  for  the  operational  plans,  along  with  guidelines 
and  examples 

Though  the  plan  comes  from  the  PAT  as  a  team,  the  PAT  leader  may  be  the 
only  one  working  on  the  first  draft  of  the  plan.  The  other  identifi^  team 
members  may  be  involved  to  a  lesser  extent  until  implementation  actually 
begins. 

Tfechnolpgy  transfer-related  activities  are  covered  in  Using  New  Techndo^ 
A  Technology  Tranter  Guidebook  (Software  Flroductivi^  Consortium  1993e.) 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Ihsk  each  PAT  to  develop  a  plan  to  address  improvements  in  its  assigned 
technical  area,  including  estimates  of  resources  and  schedules. 

3.  Task  the  SC  to  Develop  a  Tactical  Plan.  The  SC  has  responsibilities  to 
perform  during  the  implementation  of  process  improvements  and  should 
have  a  plan  for  executing  its  duties. 

The  SC’s  role  is  to  provide  support  for  process  improvement.  Support 
comes  in  many  forms,  such  as  (I^wler  and  Rifkin  19%): 

•  Developing  organizational  policies  for  process  activities 

•  Resource  and  process  management 


•  Building  consensus  among  various  groups 


•  Interfacing  with  other  high-level  committees  or  corporate  planning 
offices 
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•  Developing  diarters  for  the  PG  and  PAD 

•  Preparing  strategic  plans 

•  Setting  priorities  for  actions 

Another  important  role  of  the  SC,  due  to  the  high  organizational  level  of 
its  members,  is  to  reinforce  sponsorship  and  commitment  to  process  im¬ 
provement  throughout  the  organization.  Emi^iasizing  the  responsibility 
and  value  of  the  SC  will  motivate  middle  management  to  become  suj^rt- 
ers  of  process  improvement.  The  SC  should  communicate  information 
concerning  process  improvement  to  many  other  areas  of  the  organization. 
Communication  of  this  information  may  come  in  many  forms: 

•  Providing  additional  process  improvement  concept  training 

•  Providing  brown-bag  lunches  on  process  improvement 

•  Providing  status  briefings  on  the  strategies  or  direction  of  process 
improvement  within  the  organization 

This  information  flow  encourages  others  to  initiate  process  imfH'ovement 
activities  and  provides  visibility  of  your  organization’s  |H^ocess  improvement 
success. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Ask  the  SC  to  develop  a  plan  to  address  its  responsibilities  for  this  (tycle, 
including  estimates  of  resources  and  schedules. 

4.  Task  the  PG  to  Develop  a  Tactical  Plan.  The  PG  has  responsibilities  to 
perform  while  the  PAD  implement  specific  process  improvements.  Some 
ongoing  activities  of  the  PG  are: 

•  Establishing  and  maintaining  management  sponsorship  and  commitment 

•  Maintaining  collaborative  relationships  with  managers  and  engineers 

•  Setting  appropriate  expectations  for  engineers  and  managers 

•  Arranging  for  relevant  training  and  education 

•  Tladdng,  monitoring,  and  reporting  the  status  of  software  process 
improvement  efforts 
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•  Participating  in  organizational  improvement  initiatives 

•  Participating  in  organizational  planning 

In  addition  to  these  program  management  activities,  the  PG  is  responsible 
for  performing  tedmical  activities,  such  as: 

•  Defining  and  maintaining  an  organizational  larocess  architecture,  in 
collaboration  with  managers  and  engineers 

•  Working  with  each  PAT  to  ensure  that  all  processes  integrate  into  the 
organization’s  process  architecture 

•  Maintaining  a  process  database 

•  Providing  process  consultation  to  development  projects  and  managnnent 

Refer  to  Process  Engineerir^  With  the  Evolutionay  Spiral  Process  Model 
(Software  Productivity  Consortium  1993b)  for  additional  details  on 
engineering  your  organization’s  processes. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Ihsk  the  PG  to  develop  a  plan  to  address  its  responsibilities  for  this  cycle, 

including  estimates  of  resources  and  schedules. ' 

5.  Incoqiorate  Each  Tactical  Plan  Into  the  Action  Plan.  The  tactical  plans 
and  the  strategic  plan  need  to  be  assembled  into  an  action  plan.  Any  con¬ 
flicts  among  the  individual  plans  and  with  the  organizational  objectives 
and  constraints  need  to  be  addressed. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Gather  the  tactical  plans  from  eadi  PAT  the  PG,  and  the  SC,  and  incorporate 

them  into  an  action  plan. 

6.  Identify  Budget  and  StafBng.  You  need  to  identify  the  expexAed  budget 
and  staffing  requirements  for  this  qrcle,  based  on  the  resource  estimates 
provided  by  each  group  (i.e.,  the  SC,  the  PG,  and  each  PAT). 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Study  the  estimates  of  resources  and  sdiedules  from  eadt  tactical  jdan  so  that 

you  can  develop  an  overall  budget  and  the  staffing  requirements  to  adiieve 
the  objectives  of  this  cyde.  Specifically,  you  need  to  do  the  following: 

•  Identify  needed  internal  and  external  resources,  including  trainers  and 
consultants,  to  assist  you  in  areas  with  low  levels  of  expertise. 
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6.  Ckift  a  Oonne:  FIm 


•  Identify  and  record  the  expected  costs  of  the  imivovements  made  in 
this  cycle.  Specifically,  you  need  to  understand  the  costs  for  training 
(both  to  develop  training  materials  and  to  provide  the  training), 
increased  support  requirements,  integration  time  and  costs,  and  initial 
productivity  loss  due  to  the  learning  curve.  Refer  to  Head  (198S)  for 
guidance  on  training  cost  analysis. 

•  Allocate  time  and  resource  contingencies  to  address  such  [voblems  as 
emerging  resistaiKe  to  imivovements,  waning  sponsorship  and 
commitment,  and  interference  by  other  seemiqgfy  independent  cfaapges. 

7.  Develop  Measures  of  Success.  Define  the  success  criteria  for  the  current 
cycle,  and  define  when  in  the  cycle’s  implementation  you  will  assess 
progress  against  these  success  aiteria. 

Cyck  1,2  This  task  is  not  performed  imtil  adequate  sponsorship  is  established. 

Cyck  N  Guidance  for  defining  the  success  criteria  and  data  collection  requirements 
are  given  below.  Refer  to  Appendix  H  for  more  information  regarding  jx^o- 
cess  and  product  measures,  and  a  method  to  help  you  define  measures  based 
on  your  goals. 

Success  Criteria.  The  tide's  success  criteria  are  the  measures  against  which 
you  will  determine  when  the  implementation  has  reached  such  a  state  that 
you  should  do  a  full-scale  review  and  update  of  plans  as  described  in 
Step  5.  Your  success  aiteria  must: 

•  Support  both  the  cycle  and  software  process  improvement  program 
objeaives  and  strategies 

•  Define  when  the  implementation  will  be  complete  for  this  circle 

•  Ensure  progress  against  the  overall  program  objectives 

Data  Collection  Bequirements.  The  cycle’s  data  collection  requirements  are 
used  both  to  assess  empirically  the  impacts  of  the  improvements  on  the 
process  and  process  users,  and  to  determine  progress  against  the  success 
aiteria  defined  for  the  c^cle.  Your  data  collection  requirements  must: 

•  Be  tied  directly  to  this  tide’s  success  aiteria 

•  Include  spedfications  of  what  data  will  be  colleded  by  whom  and  from 
whom 

•  Ensure  that  data  collected  includes  data  received  from  talking  to  and 
surveying  process  users  to  determine  their  level  of  satisfaction  with  the 
new  processes 


^  Sponsor 


nn  Champion 

© 


5 


IVocess 

User 


Change 

A^t 


6-9 


6.  diait  a  Coune:  Pbm  Improvements 


•  Identify  the  specific  times  during  the  cycle’s  im^dementation  period 
(‘‘snapshots**)  when  implementation  should  be  assessed  against  the 
success  criteria. 


•  Specify  how  the  level  of  process  improvements  will  be  measured.  For 
example,  if  {voject  planning  polides  and  procedures  do  not  exist  in 
your  organization,  then  you  may  not  want  to  have  as  success  measure 
the  degree  of  institutionalization.  A  more  realistic  measure  may  be  to 
have  all  polides  and  procedures  documented  and  all  personnel 
trained. 

8.  Analyze  Risks  Assodated  With  the  Action  Plan.  Now  that  you  have  a 
greater  understanding  of  the  implementation  details,  you  may  identify 
new  risks  to  achieving  your  program  and/or  cycle  objectives.  For  example, 
after  identifying  the  budget  and  staffing  requirements,  you  may  determine 
that  you  do  not  have  an  adequate  staffing  level  to  achieve  your  objectives, 
lb  mitigate  this  risk,  you  could  either  rescope  your  cycle  objectives  and  re¬ 
plan  the  activities,  or  talk  to  your  sponsor  about  committing  more 
resources.  Refer  to  the  activity  Analyze  and  Resolve  Risks  in  Step  2  for 
more  guidance  on  risk  analysis.  You  may  choose  to  spin  off  a  spiral  to 
handle  either  of  these  cases. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Document  any  additional  risks  that  have  been  identified  because  of  your 
greater  understanding  of  the  tactical  plans.  Evaluate,  plan,  and  execute 
risk  mitigation  strategies.  Update  the  risk  management  plan  to  reflect  the 
new  risks  and  mitigation  strategies. 

9.  Finalize  the  Action  Plan.  You  need  to  prepare  a  formal  plan  that  covers 
what  needs  to  be  done  to  improve  the  organization*s  process  in  this  cycle. 
A  final  draft  should  be  released  within  four  to  six  weeks  of  commencing 
this  activity. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Document  in  the  action  plan  all  the  information  you  have  gathered  in  this 

activity  and  prepare  the  plan  for  release  to  your  sponsor. 


Measures 

In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 
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•  Time  and  effort  spent  develof^  the  strat^c  and  tactical  [dans  (by 
SC.  PG,  and  PAR) 

•  Size  of  the  strategic  and  tactical  plans  (e.g.,  number  of  pages) 

•  Quality  of  the  strategic  and  tactical  plans 

•  Time  and  effort  spent  incorporating  tactical  plans  into  the  action  plan 

•  Number  of  action  items 

•  Number  of  recommendations  addressed  in  the  action  i^an,  not  addressed 
in  the  action  plan,  and  items  not  found  in  the  recommendatimis 

•  Number  of  items  addressed  in  the  action  plan  that  are  not  found  in  the 
recommendations 

•  Time  and  effort  spent  identifying  budget  and  staff  requirements 

•  Time  and  effort  spent  developing  measures  of  success 

•  Time  and  effort  spent  finalizing  the  action  plan 

•  Size  of  the  action  plan  (e.g.,  number  of  pages) 

•  Quality  of  the  action  plan 

•  Planned  size  and  budget  of  the  PG 

•  Planned  number,  size,  and  budget  for  the  PAR 

•  Number  of  risks  identified,  analyzed,  and  mitigated 

•  Time  and  effort  spent  identifying  and  resolving  risks 

•  Time  and  effort  spent  updating  the  risk  management  plan 


Stop  Criteria 

This  activity  is  complete  when  you  have  developed  an  action  plan  that 
details  what  needs  to  be  done,  including  the  formation  of  PAR,  if  needed, 
to  improve  the  organization’s  process  during  this  cycle. 
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6.  Chart  «  Counc:  Plan  Improvemenis 


6^  COMMIT  TO  ACTION  PLAN 


This  activity  begim  in  Step  3,  Plan  Improvements. 


Overview 


Your  objective  in  this  activity  is  to  get  all  stakeholders — including 
sponsors,  diampions,  change  agents,  and  process  users — ^to  commit  to  the 
action  plan  for  this  (^cle.  A  key  part  of  this  activity  is  for  the  sponsors  to 
publicize  the  commitment  across  the  organization.  Ample  opportunity 
should  be  provided  for  the  stakeholders  to  review  and  comment  on  the 
plan.  Based  on  the  review  results,  you  may  determine  that  you  need  to 
revise  the  plan. 


Start  Criteria 


Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Approved  cycle  strategy,  objectives,  and  constraints 

•  Detailed  action  plan  for  the  cycle 

•  Understanding  of  who  are  the  stakeholders  for  this  commitment 


Tasks 


You  need  to  obtain  approval  from  the  identitied  stakeholders  on  the  action 
plan  and  commitment  to  proceed. 

1.  Obtain  Agreement  Fkom  Change  Agents,  Champions,  and  Process 
Users.  Seek  approval  first  from  all  identified  stakeholders  other  than  the 
sponsors.  The  sponsors  may  be  reluctant  to  approve  the  plan  until  there 
is  buy-in  from  all  the  other  players  involved. 


Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 
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Cycle  N  You  need  to  get  the  identified  champions,  change  agents,  and  process  users 

to  review  and  approve  the  plan.  You  may  need  to  go  through  several 
iterations  in  the  review  process  before  they  will  approve  it. 

2.  Obtain  Commitment  F^om  Sponsors.  After  you  have  buy-in  from  the 
identifled  champions,  change  agents,  and  process  users,  present  your  plan 
to  the  identified  sponsors  for  approval.  Your  presentation  should  include: 

•  Description  of  the  plan 

•  How  the  plan  supports  the  cycle  objectives  and  makes  progress  against 
the  overall  process  improvement  objectives 

•  How  this  plan  is  likely  to  affect  each  part  of  the  organization  for  this 
cycle,  especially  the  groups  related  to  the  sponsors  you  are  briefing 

•  Estimated  cost  and  time  frame  for  the  implementation  of  this  plan 

Depending  on  your  situation,  you  may  decide  to  stagger  the  presentations, 
targeting  first  those  sponsors  who  are  more  supportive,  in  order  to  build 
a  stronger  case  for  those  sponsors  who  arc  less  supportive. 

You  may  go  through  several  iterations  of  your  presentation  to 
management  before  you  get  a  final  decision  to  go  ahead  with  the  imple¬ 
mentation.  If  so,  return  as  necessary  to  any  task  in  this  activity  or  in  the 
Define/Update  Action  Plan  activity  to  secure  the  dedsion  to  proceed. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  You  will  seek  commitment  from  the  authorizing  and  reinforcing  sponsors. 

3.  Publicize  the  Commitment.  After  approving  the  action  plan,  the 
sponsors  need  to  publicize  their  support  and  commitment  throughout 
their  organization  to  keep  everybody  informed,  to  reinforce  the 
importance  of  process  improvement,  and  to  help  prepare  everybody  for 
the  changes  ahead. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Assist  the  sponsors  with  developing  a  communication  strategy  to  publicize 

commitment.  Use  the  influence  strategy  created  in  Step  1,  Understand 
Context. 


Measures 

In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 
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6.Ch»rt>CouT»e:  PUn  Imprcwmento 

•  Time  and  effort  spent  reviewing  the  action  plan  with  change  agents, 
champions,  and  process  users 

•  Number  of  persons  interacted  with  during  the  review 

•  Time  and  effort  spent  developing  a  management  presentation 

•  Size  of  the  management  presentation  (e.g.,  number  of  charts) 

•  Quality  of  the  management  presentation 

•  Time  and  effort  spent  meeting  with  sponsors 

•  Number  of  presentations  to  and  meetings  held  with  sponsors 

•  Time  and  effort  spent  publicizing  conunitment 

•  Number  of  persons  to  whom  and  places  where  commitment  was 
publicized 


Stop  Criteru 

This  activity  is  complete  when: 

•  You  have  secured  commitment  from  all  identified  stakeholders  on  the 
action  plan 

•  The  sponsors  have  publicized  their  commitment  on  the  action  plan 
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7.  JUST  DO  IT:  IMPLEMENT  IMPROVEMENTS 


WhOe  the  dust  is  still  on  your  feet,  sell  what  you  have  brought  to  the  market. 


Section  Objective 

Provide  ffiidancefor 
implementing  and 
managing  process 
improvements 


Bab^onian  Iklmud,  Pesahim 

Once  the  action  plan  is  approved,  implementation  does  not  happen  just  by 
turning  on  a  switch.  The  action  plan  must  be  implemented  the  PG,  PAK, 
and  process  users,  managed  by  the  PG  and  SC,  and  Supported  by  the  spon¬ 
sors  and  champions.  This  section  provides  guidance  for  the  activities 
shown  in  Figure  7-1. 


Figure  7-1.  Implement  Improvements  Activities 


Dolt:  Imptement  ImprovemenU 


7.1  IMPLEMENT 


This  activity  begins  in  Step  4,  Implement  Improvements. 


Overview 


Your  (^jective  is  to  carry  out  the  action  plan  for  this  cyde.  Each  group— the 
PG,  the  SC,  and  each  will  implement  the  work  described  in  the 
detailed  tactical  plan  they  developed  in  the  previous  step.  This  activity  should 
be  performed  with  the  same  urgency  as  you  would  a  software  development 
project  for  an  external  diuit  This  activity  is  performed  in  parallel  with  the 
Mwage  and  Monitor  activity. 

The  majority  of  the  work  that  occurs  in  this  activity  is  detailed  in  the 
individual  tactical  plans  and  performed  by  the  assigned  PAIk.  lb 
implement  process  improvements  in  technical  areas,  the  PAIk  should 
follow  the  post-planning  guidance  (Cycle  N)  as  described  in  Using  New 
Technologies:  A  Technology  Thinker  Guidebook  (Software  Productivity 
Consortium  1993e). 

While  the  PAB;  address  improvements  in  specific  technical  areas  on 
specific  software  projects,  the  PG  and  SC  should  focus  on  performing  the 
work  described  in  their  respective  plans.  Figure  7-2  depicts  the 
relationship  and  interactions  among  these  three  groups  and  the  projects 
(Fowler  and  Rifkin  1990). 


Start  Criteria 

Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Approved,  detailed  action  plan,  including  tactical  plans  for  each  PAT, 
the  SC,  and  the  PG 

•  Resources  to  perform  the  improvements 


Tasks 


You  will  implement  the  work  described  in  each  tactical  plan  developed  in 
the  previous  step. 
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1.  Implemeat  the  Adion  Plan.  The  action  plan  is  comprised  of  a  set  of 
tactical  plans,  one  for  the  SC,  one  for  the  PO,  and  one  for  each  PAT 
established.  Each  group  carries  out  the  actions  specified  in  its  respective 
tactical  plan. 


Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 


Cycle  N  This  task  may  be  accomplished  by  having  each  group  spin  off  a  spiral  to 
address  its  specific  responsibilities.  This  approach  provides  a  means  for 
each  group  to  address  risks  to  its  objectives  and  evolve  its  plans.  Each 
group  is  responsible  for  updating  its  respective  plans,  based  on  lessons 
learned.  Changes  in  the  plans  are  communicated  to  the  PC. 


Measures 


In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 
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7.  Juil  Do  It  Imptement  Improwments 


•  Size  and  budget  of  the  PG 

•  Number,  size,  and  budget  for  the  PAB 

•  Time  and  effort  spent  implementing  the  action  plan 

lb  get  accurate  information  on  this  measure,  it  is  best  for  each  group 
to  record  the  time  and  effort  spent  implementing  its  respective  tactical 
plan.  If  the  groups  are  using  the  spir^  process  to  manage  their  activi¬ 
ties,  the  measures  would  be  similar  to  those  listed  with  each  activity  in 
this  guidebook. 

•  Causes  for  delayed  implementation 

•  Time  and  effort  spent  updating  the  action  plan 

•  Causes  for  updating  the  action  plan 

•  Number  of  activities  updated,  either  new  or  revised 

•  Size  of  the  updated  action  plan  (e.g.,  number  of  pages) 

•  Number  of  times  the  action  plan  is  updated 

•  Volatility  of  the  action  plan  changes  (i.e.,  number  of  critical  path 
changes) 

•  Number  of  projects  using  the  new  or  revised  process 

•  Number  of  persons  using  the  new  or  revised  process 

•  Improvements  in  processes  and  products  in  the  projects  using  the  new 
processes 

Each  PAT  develops  an  operational  plan  desCTibing  how  a  project  will 
use  the  new  processes  or  technologies.  Included  in  this  operational 
plan  is  a  list  of  measures  that  the  project  will  collect  to  quantify  the 
effects  of  process  improvement.  Appendix  H  provides  an  overview  of 
software  product  and  process  measurement. 

•  Qualify  of  the  new  or  revised  process 

•  Process  user  satisfaction  ratings 

•  Number  of  traim'ng  days  for  the  PG,  the  PAR,  and  the  process  users 
by  training  type  (e.g.,  team  dynamics  training  versus  specific  process 
training) 
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These  measures  should  not  be  collected  just  once,  but  at  regular  intervab 
over  the  course  of  imi^ementation.  This  provides  trend  inftMrmation  that 
you  can  monitor  as  the  implementation  progresses. 


This  activity  is  complete  when  you  have  completed  the  imidementation  as 
defined  in  the  action  plan  for  this  (^cle,  induding  all  tactical  plans. 


7.JiMtDoli;lnipkaiieinIiiipro»ciiieim 


IJ,  MANAGE  AND  MONITOR 


This  activity  begins  in  Step  4,  Implement  Improvements. 


Overview 

Your  objective  in  this  activity  is  to  manage  the  implementation  of  process 
improvements  and  to  collect  data  to  be  used  in  later  review  activities.  This 
activity  should  be  performed  in  the  same  manner  as  a  software  develop¬ 
ment  project  for  an  external  client.  In  fact,  it  is  useful  to  adopt  analogous 
structures  and  processes  (e.g.,  schedule  monitoring,  status  meetings,  and 
reports). 

There  are  crucial  differences  between  working  on  a  such  a  project, 
however,  and  implementing  process  improvements.  Inevitably,  as  the 
process  unfolds,  there  will  be  resistance  and  fear — the  Ity-products  of 
major  change.  These  issues  need  to  be  addressed  by  bringing  them  out  in 
the  open  and  addressing  them  the  best  way  you  can.  Refer  to  Section  2.2, 
Human  Responses  to  Change  Are  Complex. 


Start  Criteria 

Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Approved  action  plan,  including  all  tactical  plans 

•  Resources  to  manage  and  monitor  the  implementation 


Tasks 

The  primary  task  in  this  activity  is  managing  the  implementation  of  the 
action  plan  for  this  tycle.  The  other  tasks  are  listed  here  as  separate  tasks 
to  emphasize  their  k^  role  in  the  success  of  process  improvement: 
addressing  resistance  to  change  and  supporting  the  PAD.  This  activity  is 
performed  in  parallel  with  the  Implement  activity. 
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Cycle  1,2 
Cycle  N 


Cycle  1,2 
CydeN 


1.  Manage  the  Implemeatation.  Implementation  of  the  tactical  [dans 
shoiild  demonstrate  visible  [^ogress  toward  the  objectives  of  the  cycle  and 
the  process  improvement  program.  If  the  implementation  is  not  managed, 
visibili^  becomes  almt^t  impossible. 

This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Manage  the  implementation  just  as  you  would  any  other  software 
development  project.  Specifically,  you  undertake  the  following: 

•  Begin  the  implementation  with  a  kickoff  meeting,  inviting  champions, 
change  agents,  and  senior  management  (sponsors).  Review  ea^  im¬ 
plementation  task  and  the  overall  process  improvement  sdiedule. 
Confirm  resource  (people,  time,  money)  availability.  Create  enthu¬ 
siasm  for  the  process  improvement  cycle.  The  meeting  should  end  with 
an  agreement  on  w^en  the  implementation  tasks  should  commence 
and  when  the  next  meeting  will  be  held. 

•  Hold  regular  meetings  during  the  implementation  to  highlight  issues 
and  problems  that  each  PAT  may  face.  Resolve  conflicts  and 
misunderstandings  among  the  PAR. 

•  Hack  progress  of  the  implementation  against  the  schedules  defined  in 
the  action  plan. 

•  Track  progress  against  your  planned  budget. 

•  Publicize  periodically  the  progress  of  the  implementation  to  your 
management,  the  SC,  other  sponsors,  champions,  and  process  users 
within  the  organization. 

•  Maintain  communication  among  all  stakeholders  (sponsors,  change 
agents,  champions,  and  process  users)  on  the  status  of  the 
implementation.  This  will  continue  process  improvement  momentum 
and  buy-in. 

2.  Gather  Implementation  Data.  Gather  data  during  the  implementation 
to  show  progress  toward  your  cycle  objectives.  This  data  will  be  used  in  the 
Review  Progress  activity  in  Step  5.  The  data  to  be  collected  is  defined  in 
the  action  plan  (see  Ttsk  7,  Develop  Measures  of  Success),  in  the  Define/ 
Update  A^on  Plan  activity. 

This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Gather  and  analyze  information  to  determine  if  process  improvements  are 
progressing  as  planned.  Spedfically,  you  undertake  the  following: 
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Cycle  1,2 


•  Ensure  that  you  are  receiving  progress  reports  from  the  PAI^  on  a 
regular  basis,  as  defined  in  each  tactical  plan. 

•  Gather  additional,  potentially  subjective,  information  from  the  PAK 
and  the  pilot  projects  involved  with  the  improvements. 

Check  the  information  you  have  gathered  against  the  measures  and 
success  criteria  outlined  in  the  action  plan  to  determine  if  you  are 
progressing  as  expected.  If  the  implementation  achieves  completion 
criterion,  determine  whether  you  want  to  continue  progress  with  the 
implementation  or  move  on  to  the  next  step.  Review  and  Update,  and 
formally  analyze  the  implementation  at  this  point.  Keep  the  following 
guidance  in  mind  when  making  this  determination: 

•  Before  you  move  to  the  next  activity  for  a  formal  review,  ensure  that  the 
implementation  has  been  completed  to  such  a  point  that  it  makes  sense 
to  proceed  with  the  next  step.  If  you  stop  implementation  too 
early— before  improvements  have  been  made — you  risk  reporting 
benefits  that  do  not  accurately  portray  reality.  If  you  wait  too  long,  you 
risk  dampening  the  enthusiasm  for  the  change  and/or  losing  management 
commitment  not  publidzing  success  stories  early  enough. 

•  If  you  do  not  make  the  expected  progress,  find  out  what  has  happened. 
Slowed  progress  might  be  due  to  problems  in  the  action  plan,  problems 
with  vendor  support,  problems  with  political  and  management  sup¬ 
port,  problems  with  stakeholder  buy-in,  unexpected  or  expected  risks 
occurring,  problems  with  defining  the  new  process,  or  problems  with 
the  process’s  interface  to  the  environment.  Stop  or  slow  down  the  im¬ 
plementation,  determine  how  to  resolve  the  problems,  and  replan,  re¬ 
formulate,  or  reperform  the  appropriate  taslK  to  resolve  the  problems. 
Then  continue  the  implementation. 

•  Ongoing  implementation  assessment  should  examine  not  only 
quantitative  progress  towards  the  (^cle  objectives,  but  also  whether 
the  new  process  fits  the  process  users’  needs  and  expectations  in  a 
qualitative  sense.  Is  the  process  being  used  in  ways  that  are  true  to  the 
intent  of  those  who  selected  and/or  designed  the  improved  process? 
Does  the  implementation  maximize  the  process’s  potential? 

3.  Support  the  PATs.  Once  the  PAI^  have  become  established,  they  must 
receive  adequate  support  while  they  install  and  use  the  new  processes.  If 
they  do  not  get  adequate  support,  the  probability  of  full  acceptance  and  use 
of  a  process  will  decrease  rapidly. 

This  task  is  not  performed  until  adequate  sponsorship  is  established. 
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Cycle  N  Provide  su^^rt  as  defined  in  the  action  plan  for  this  cyde.  The  suiqx>rt 
you  provide  can  indude: 

•  H-aining  and  education  coordination 

•  Process  consulting 

•  Expertise  on  implementing  organizational  diange 

•  Access  to  technology  experts,  preferably  permanently  or  temporarily 
transferred  to  the  group 

^7^  4.  Analyze  Risks  Assodated  ^th  Implementation.  Now  that  you  are 

implementing  process  improvements,  you  may  identify  new  risks  to 
achieving  your  program  and/or  cycle  objectives.  For  trample,  a  pilot 
project  may  experience  team  d^amics  problems.  Plan  and  execute 
mitigation  strategies.  For  more  guidance  on  risk  analysis,  refer  to  the  Ana¬ 
lyze  and  Resolve  Risks  activity  in  Step  2.  You  may  choose  to  spin  off  a  spiral 
to  handle  risk  analysis. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 


CycUN 


Document  any  additional  risks  that  have  been  identified.  Evaluate,  plan, 
and  execute  risk  mitigation  strategies.  Update  the  risk  management  plan 
to  reflect  the  new  risks  and  mitigation  strategies. 

5.  Manage  Resistance  to  Change.  Despite  the  fact  that  you  have  sought 
commitment  and  approval  throughout  the  process,  you  wUl  still  encounter 
stakeholders  who  resist  the  change  throughout  the  implementation.  Listed 
here  are  some  common  forms  of  resistance  (Block  1981): 

•  Give  Me  More  Detail  The  stakeholder  wants  to  know  everything  about 
what  is  happening.  No  matter  how  much  information  you  give,  it  is  nev¬ 
er  enough.  This  fypically  occurs  when  sponsors  ask  for  ROI  data  to 
demonstrate  the  value  of  process  improvement. 

•  Flood  You  With  Dettdl.  The  stakeholder  gives  you  more  information 
than  you  requested,  focusing  on  minute  details. 

•  Silence.  The  stakeholder  is  passive  and  has  no  particular  reaction  to 
what  you  are  saying.  When  asked  for  feedback,  the  typical  response  is 
"Keep  on  going,  I  don’t  have  any  problems  with  what  you're  saying.  If 
I  do.  I’ll  interrupt."  This  may  be  a  signal  of  covert  resistance. 

•  Nonverbal  Messages.  The  stakeholder  may  be  sending  nonverbal 
messages  of  resistance,  such  as  clenching  fists,  moving  away  from  you. 
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or  shaking  his  head  when  speak.  Look  for  nonverbal  behavior  as 
a  cue  to  resistance. 

Resistance  to  change  can  be  managed  once  it  has  been  identified.  Some 
ways  to  surface  resistance  are: 

•  Surveys 

•  Suggestion  boxes 

•  Fbrums  or  “all-hands”  meetings 

•  Third-party  (internal  or  external)  interviews 

•  Hot  lines 

•  One-on-one  discussions 

For  these  techniques  to  be  most  effective,  they  need  to  be  performed 
continuously,  not  just  once.  Covert  resistance  will  not  surface  on  the  first 
try  to  expose  it,  but  only  after  you  have  created  a  safe  atmosphere  for 
stakeholders. 

Cycle  1^2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  \Wth  your  understanding  of  the  two  typical  responses  to  change,  discussed 

in  Section  2,  identify  the  potential  resistors  and  their  behaviors.  You  can 
best  manage  their  resistance  by  doing  the  following: 

•  Identify  the  cause  of  resistance  from  the  stakeholder's fhane  of r^erence.  It 
is  very  important  for  you  to  understand  the  stakeholder’s  point  of  view. 
You  may  not  agr.  i  with  that  view,  but  you  should  recognize  that  it  is 
very  important  to  the  stakeholder. 

•  Exjdain  the  char^  in  Ihe  stakdiolder'sfrxune  of  rtference.  The  stakeholder 
needs  to  understand  how  {x-ocess  improvement  will  affect  his  or  her 
day-to-day  work  and  career. 

•  Establish  realistic  expectations.  Acknowledge  that  there  will  be  a  feeling 
of  uncertainty  as  the  organization  and  its  processes  change,  but  that  is 
to  be  expected.  Describe  to  the  stakeholders  how  you  will  manage  the 
transition. 

•  Allow  the  stakeholders  to  express  their  concerns.  Use  techniques  to 
surface  resistance  repeatedly.  Ask  open-ended  questions,  and  then  be 
quiet  and  listen  intently. 

•  Involve stakeholdersmnxichingyourqt^anization’s objectives.  When  at  all 
possible,  provide  opportunities  for  the  stakeholders  to  be  involved  in 
planning,  process  definition,  and  other  decision-making  activities. 
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Measures 
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6.  Reinforce  Sponsor  Conunitment.  Most  sponsors  feel  that  their  job  is  all 
downhill  during  the  implementation  of  process  improvements.  Not  so. 
Without  maintaimng  the  visibility  and  continually  stressing  the  impor¬ 
tance  of  this  change,  the  organization  is  likely  to  slip  back  into  its  old  hab¬ 
its.  It  is  much  easier  to  revert  to  old  habits  than  to  persevere  through  the 
change. 


Cycle  This  task  is  not  performed  until  adequate  sponsorship  is  established. 
Cycle  N  During  this  period  of  transition,  assist  the  sponsor  with  reinforcement  by: 


•  Involving  the  stakeholders  in  implementing  process  improvements 

•  Providing  the  resources  to  achieve  the  cycle  objectives 

•  Rewarding  supporters  of  process  improvement 

•  Motivating  stakeholders  who  are  resistant 

•  Communicating  the  progress  of  process  improvement,  always  focusing 
on  the  desired  state 


In  order  to  quantify  the  resources  spent  on  pr<x«ss  improvement,  aiid  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  Time  and  effort  spent  managing  the  implementation,  including: 

-  Project  tracking  and  oversight 

-  Updating  the  tactical  plans 

-  Progress  meetings 

•  Number  of  identified  risks  that  occurred 

•  Number  of  risks  identified,  analyzed,  and  mitigated 

•  Time  and  effort  spent  identifying  and  resolving  risks 

•  Time  and  effort  spent  updating  the  risk  management  plan 

•  Number  of  organizational  issues  raised  and  length  of  time  until  resolution 
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•  Time  and  effort  spent  gathering  implementation  data 

•  Time  and  effort  spent  supporting  the  FAB  and  pilot  projects,  including 
training  coordination,  process  consulting,  and  organizational  change 
assistance 

•  Time  and  effort  spent  managing  resistance  to  change 

•  Time  and  effort  spent  reinforcing  sponsor  commitment 


Stop  Criteria 


This  activity  is  complete  when  the  implementation  for  this  cycle  has  been 
completed  as  defined  in  the  action  plan  (set  of  tactical  plans). 
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7J  REVIEW  PROCESS  IMPROVEMENTS 


This  activity  begins  in  Step  4,  Implement  Improvements. 


Overview 

Your  objective  in  this  activity  is  to  gather  the  process  assets  that  were 
CTeated  or  changed  during  the  implementation  of  improvements.  A  pro¬ 
cess  asset  is  any  artifact  that  the  organization  considers  useful  in  perform¬ 
ing  the  activities  of  process  definition  and  maintenance,  such  as  the 
organization’s  standard  software  process,  descriptions  of  software  life 
cycles  approved  for  use,  tailoring  guidelines  and  CTiteria,  and  any  process- 
related  documentation.  The  process  assets  will  be  baselined,  or  placed 
under  configuration  control,  in  the  Review  Progress  activity  in  Step  5. 


Start  Crtteru 

Use  the  following  types  of  information  and/or  working  Knowledge  as 
inputs  to  this  activity: 

•  Approved  action  plan  for  this  Qrcle 

•  Process  assets  created  or  updated  during  the  implementation 


In  this  activiQr,  you  collect  and  review  the  process  assets  defined  or  updated 
during  implementation,  and  collect  and  review  the  lessons  learned. 

1.  Collect  and  Review  Process  Assets.  Process  assets  are  valuable  to  the 
organization  since  they  provide  historical  information  that  can  be  used  for 
future  planning  activities. 
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Here  is  an  initial  list  of  process  assets  that  you  should  be  concerned  with: 

•  Action  plan,  induding  tactical  plans 

•  Risk  management  plan 

•  Description  of  the  improved  processes  from  each  PAi;  e.g.,  cfaeddist 
of  tasks,  process  model,  or  textual  description 

•  Data  collected  during  the  implementation  that  was  used  to  assess 
progress  against  the  plan 

•  Organization  polices 

•  Ihiloring  guidelines  and  aiteria  for  projects 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Gather  the  descriptions  of  the  process  assets  that  were  defined  or  updated 

during  this  cycle.  Review  these  assets  with  each  PAT  to  ensure  that  they  are 
adequately  dcxmmented  and  understandable. 

The  process  assets  that  are  collected  and  reviewed  will  be  baselined  in 
Step  S,  Review  and  Update. 

2.  Collect  and  Document  Lessons  Learned.  The  lessons  learned  are  both 
strategic  and  tactical  in  nature.  They  focus  on  specific  implementation  is¬ 
sues,  and  should  come  from  the  stakeholders  of  each  improved  process, 
such  as  the  PAT,  the  process  users  (i.e.,  pilot  projects),  managers  of  the 
pilot  projects,  and  senior  management. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Gather  and  document  the  lessons  learned  during  the  previous  steps  in  this 

cycle,  including  organizational  change  issues,  risk  analysis,  action  plan 
development,  and  implementation. 

These  lessons  learned  will  be  shared  with  the  organization  in  Step  5, 
Review  and  Update,  and  also  baselined  as  a  process  asset. 


Measures 

In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 


7-14 


TAMDolt: 


•  Time  and  effort  spent  collecting  and  reviewing  process  assets 

•  Number  of  persons  involved  in  the  review 

•  Number  of  change  requests,  open  or  resolved,  per  process  asset 

•  Number  of  process  assets  created  or  revised 

•  Time  and  effort  spent  collecting  and  documenting  lessons  learned 

•  Number  of  lessons  learned  that  were  collected  and  documented 


StopCriteiua 

This  activity  is  complete  when: 

•  You  have  prepared  a  description  of  each  process  asset  that  was 
generated  or  updated  during  the  implementation 

•  You  have  prepared  a  description  of  the  lessons  learned 


7-15 


7-16 


8.  STEER  TOWARD  SUCCESS:  REVIEW  AND 

UPDATE 


Managing  in  accordance  with  a  strategic  plan  is  a  learned  art.  The  longer  you  use  the  tod,  the  better 
you  are  aUe  to  manage  with  it. 


Seetioa  M/ective 

1.  Provide  guidance  for 
revieuwgthe  results  of 
the  implementation 

2.  Provide  gpidance  for 
deciding  how  to  proceed 


R.  Henry  Mig^onev  An  MBOApproach  to  Long-Range  Planning 

Once  the  process  improvements  have  been  made  in  this  t^e,  you  need  to 
review  the  progress  against  the  objectives  in  both  the  action  {dan  and  the 
process  improvement  program  plan  (strategy).  Based  on  this  review,  you 
will  update  your  plans  and  strategy,  define  recommendations  for  proceed¬ 
ing,  and,  if  you  receive  commitment,  continue  with  another  t^cle  of  pro¬ 
cess  improvements.  This  section  provides  guidance  for  the  activities  shown 
in  Figure  8-1. 


FigureS-l.  Review  and  Tpdate  Activities 
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8.  Steer  Tb»wdSiiooeiK  Review  and  Upditft 


8.1  REVIEW  PROGRESS 


This  activity  begins  in  Step  5,  Review  and  Update. 


Overview 

Your  objective  in  this  activi^  is  to  perform  a  formal  review  of  the  jn-ogress 
made  in  the  current  cyde  in  terms  of  the  cyde  and  [X'ocess  improvement 
objectives.  This  indudes  comparing  the  actual  measures  of  the  imj^e- 
mentation  to  those  estimated  in  the  action  {dan,  examining  success  criteria 
to  ensure  they  were  met,  and  reviewing  lessons  learned.  You  will  analyze 
how  the  progress  made  in  the  current  (^e  impacts  the  remainder  of  the 
process  improvement  program.  This  information  will  be  used  in  the  de¬ 
fine/update  program  plan  activity  to  develop  jdanning  documents  before 
obtaining  commitment  to  proceed.  You  r^I  also  baseline  the  process 
assets  created  or  updated  during  this  <^e. 

In  performing  this  activity,  oplidtly  and  actively  solidt  partidpation  from 
all  stakeholders  during  the  dedsion  {vocess. 


Start  Criteria 

Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 

•  Approved  action  |dan  for  this  cycl  ^ 

•  Approved  program  and  cycle  objectives,  constraints,  and  strategy 

•  Data  and  results  from  the  implementation 

•  Process  assets  created  or  updated  during  this  cyde 

•  Description  of  lessons  learned  in  this  cyde 


Tasks 
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You  will  compare  the  implementation  prc^ess  to  the  cyde  and  prc^am 
objectives  and  to  the  cyde  success  criteria,  review  lessons  learned,  and 
baseline  the  process  assets. 


1.  Compare  ImplmtteaUtioB  Data  to  Objectives.  You  need  to  understand 
the  prt^ess  made  toward  this  cycle’s  imi^enientatjon  objectives  and  the 
overall  program  objectives.  You  will  not  perform  these  tasks  until  all  or 
part  of  Ae  imi^ementation  has  been  completed. 

Cycle  lyl  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Arialyze  the  data  gathered  during  the  implementation  for  the  following: 

•  Plnoeesl/serSatifjiKfioii.Itisimportanttounderstandhowtheprocess 
users  perceive  the  improved  processes.  Did  they  consider  the  im¬ 
proved  ivocess(es)  to  be  a  success?  Were  they  satisfied  with  how  the 
process(es)  worked?  Did  the  users  feel  they  were  adequately  trained 
and  su[^rted? 

•  Sponsor  Satirfaction.  ^s  the  implementation  considered  a  success  by 
the  sponsors?  Did  they  feel  that  they  are  getting  a  positive  return  on 
their  investment? 

•  Process  bnprovenusa  Progyram  StrcOegy.  Did  the  realities  of  the 
imi^ementation  stray  fi-om  the  ordinal  strategy?  If  the  imi^ementation 
was  not  aligned  with  your  program  strategies,  then  revisit  your  selected 
P'c^am  strategy  and  alternative  strategies  to  determine  if  the  most 
api^opriate  strategy  was  selected. 

•  Process  Improvement  Program  Objectives.  Did  the  implementation 
make  progress  toward  the  program  objectives?  If  not,  then  examine 
your  cycle  objectives  to  determine  if  they  were  aligned  with  the  i»o- 
gram  objectives.  You  may  begin  to  lose  management  commitment  and 
sponsorship  if  you  do  not  make  progress  toward  your  goals. 

•  Cycle  Straff  and  Objectives.  Did  the  implementation  meet  your 
success  criteria  for  your  cycle?  If  not,  were  your  cycle  objectives 
unrealistic?  Did  you  select  a  viable  cycle  strategy?  Did  the  realities  of 
implementation  cause  you  to  deviate  from  your  cycle  strategy? 

•  Otho"  Impacts.  Consider  other  impacts  to  your  implementation  that 
were  unforeseen  during  the  planning  stage.  These  impacts  may  have 
included: 

-  Indirect  Impacts.  Sometimes  a  completely  new  process  may  have  a 
wider  effect  than  can  be  foreseen.  This  may  include  permanent 
changes  in  job  duties,  organizational  struaures  and  processes,  or 
skill  demands.  Analyze  the  implementation  for  any  indirect 
impacts. 
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-  ImptemaOation  Processes.  Among  the  impacts  of  implementiiig 
new  processes  are  those  that  are  tied  to  the  imi^ementation  [M’o- 
cess  itself.  Understand  any  side  effects,  such  as  the  before  versus 
after  perturbations  of  organizational  life. 

Document  your  analysis  of  the  above  issues  in  an  evaluation  report 
Include  an  analysis  of  risks  (did  you  identify  the  major  ri^?)  and  whether 
risk  mitigation  plans  were  successful.  Record  lessons  learned  for  use  in 
subsequent  planning. 

2.  Review  Lessons  Learned.  You  need  to  build  awareness  of  the  Gq)erienoes 
of  the  organization  so  that  during  the  next  cyde,  you  do  not  repeat  those  ex¬ 
periences  that  had  native  side  effects,  and  you  reinfcvce  those  e3q)erienoes 
that  had  positive  side  effects. 

Cyck  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cyck  N  Review  the  lessons  learned  gathered  in  Step  4,  Implement  Improvements, 

with  the  organization  as  a  whole.  Modify  the  lessons  learned  document, 
based  on  feedback  from  the  organization. 

3.  Baseline  Process  Assets.  It  is  important  to  maintain  a  collet^on  of 
artifacts  that  are  valuable  resources  to  the  organization.  These  assets  can 
be  stored  in  many  way;  a  process  asset  database  or  library  are  two  sudi 
ways. 

The  process  database  can  be  used  to  store  aaual  measurement  data 
related  to  the  process  and  work  products,  such  as: 

•  Estimates  and  actuals  of  software  size,  effort,  cost,  and  schedules 

•  Estimates  and  actuals  of  process  improvement  activities 

•  Productivity  data 

•  Peer  review  coverage  and  efficiency 

•  Number  and  severify  of  defects  found  in  software 
The  library  can  be  used  to  store  process-related  documentation,  such  as: 

•  Organizational  polides,  procedures,  and  standards 

•  Thiloring  guidelines  and  criteria  for  projects 

•  Software  development  plans 


•  Risk  management  plans 

•  Measurement  plans 

•  Process  training  materials 

•  Lessons  learned 

This  information,  in  both  the  library  and  the  database,  is  an  important 
resource  to  the  organization  and  can  help  to  reduce  the  amount  of  effort 
required  to  initiate  a  new  project  by  providing  examines  and  templates  to 
buhd  from. 

Cycle  1,2  This  task  is  not  performed  until  adequate  sponsorship  is  established. 

Cycle  N  Ardiive  the  process  assets  into  a  {vocess  asset  database,  jM-ocess  asset 
library,  and/or  some  other  storage  mechanism  for  future  reference. 


Measures 

In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  Time  and  effort  spent  comparing  implementation  data  to  objectives 

•  Number  of  progratn/c^cle  objectives  achieved 

•  Time  and  effort  spent  reviewing  lessons  learned 

•  Time  and  effort  spent  baselining  process  assets 

•  Number  of  process  assets  baselined 

•  Size  of  each  process  asset 

•  Quality  of  each  process  asset 

•  Number  of  action  plan  items  successfully  completed 

•  Number  of  reconunendations  successfully  completed 
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This  activity  is  complete  when; 

•  You  have  reviewed  the  (^e  and  program  objectives  and  the  actual 
implementation  performance  with  sponsors 

•  You  have  reviewed  lessons  learned  with  the  organization 

•  You  have  baselined  all  process  assets 
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8^  DEFINE/UPDATE  PROGRAM  PLAN 


This  activity  begins  in  Step  5,  Review  and  Update. 


Overview 


Process  improvement  does  not  just  happen.  It  requires  a  detailed  jdan  that 
sets  the  direction  of  process  improvement,  outlines  the  basic  steps  to  get 
there,  and  identifies  milestones  that  can  be  used  to  demonstrate  progress. 
It  is  well  worth  your  time  to  invest  in  developing  a  solid  plan  to  guide  your 
process  improvement  program. 

A  typical  plan  consists  of  six  interrelated  topics  (Harrington  1987): 

1.  Mission.  This  is  the  stated  reason  for  existence.  Although  the  mission 
changes  infirequently,  it  is  usually  modified  when  the  organization 
pursues  a  new  market. 

2.  Operating  Princ^Oes.  These  are  the  basic  beliefs  of  the  organization. 
These  prindples  are  reflected  in  the  culture  of  the  organization  and 
rarely  diange. 

3.  Badness  Ot^ctives.  These  objectives  set  the  long-term  direction  of  the 
organization. 

4.  Petformanee  Goab.  These  are  quantifiable  results  that  the  organization 
wants  to  accomplish  in  a  period  of  time  to  support  the  objectives. 

5.  Strategy.  The  strategy  defines  the  way  the  performance  goals  will  be 
implemented  to  achieve  the  objectives. 

6.  Tactics.  The  tactics  define  the  spedfic  tasks  to  perform  in  the  short 
term  to  move  toward  the  performance  goals. 

Your  objective  in  this  activity  is  to  develt^  a  detailed  plan  for  a  process 
improvement  program  and  to  update  these  {dans  based  on  the  jx-evious  cydes 
and  lessons  learned.  Contents  of  the  {dan  be  based  on  information  from 
many  sources,  induding  ai^  risk  anafysis  work  done  in  the  Ana^  and 
Resolve  Risks  activity  (in  Step  2)  and  your  analysis  of  the  implementation 
progress  conducted  in  tte  Redew  Progress  activity  (in  Step  S). 


Use  the  following  types  of  information  and/or  working  knowledge  as 
inputs  to  this  activity: 
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Start  Criteria 


•  Cycle  strategy,  objectives,  and  constraints 


•  Draft  risk  management  plan  developed  in  Step  2 


•  Data  gathered  during  any  im(dementation  conducted  in  this  <^e 


•  Results  from  the  Review  Progress  activity 


Tasks 

You  will  define  recommendations  to  senior  management  on  how  to 
proceed  with  process  improvement,  based  on  the  new  or  updated  process 
improvement  program  plan.  This  plan  indudes  estimates  for  the  budget 
and  schedule  for  the  first  three  steps  in  the  next  cycle. 

1.  Define  Recommendations  and  DevelopAJpdate  Program  Plans.  Define 
your  recommendation(s)  for  how  the  program  should  proceed  in  the  next 
cycle  and  develop/update  the  process  improvement  program  plan 
accordingly,  including  budgets  and  schedules  for  the  next  cycle. 

Cyde  1  In  the  first  cycle,  you  plan  the  entire  process  improvement  prc^am  and 
the  next  cycle.  Your  plan  is  based  on  the  program  strategy,  objectives,  and 
constraints,  and  the  results  of  the  risk  analysis  performed  in  the  Analyze 
and  Resolve  Risks  activity  (in  Step  2).  Spedfically,  you  need  to  do  the 
following: 

•  Develop  a  long-range  strategic  plan  for  improving  the  {xt)cesses  in  your 
organization.  Indude  the  long-range  goals  of  the  program,  the  general 
order  in  \diich  improvements  will  be  performed,  the  stakeholders  needed 
(both  authorizing  and  reinforcing),  and  the  recommended  infrastrwXure 
(SC  and  PG)  and  their  roles. 

•  Develop  a  budget  and  schedule  for  the  program. 

•  Develop  a  draft  plan  for  the  next  cyde  (Cyde  2).  This  indudes  estimates 
for  the  resources  and  budget  needed  to  address  sponsorship  and  infra¬ 
structure  issues,  analyze  and  avert  |X’c^am  risks,  select  foe  program 
strategy,  update  foe  program  fdan,  aixl  prepare  foe  cyde  fdan. 

Cycle  2  In  foe  second  cycle,  you  both  established  strong  sponsorship  for  process 
improvement  and  increased  the  level  of  organizational  readiness  (in 
Analyze  and  Resolve  Risks  activity.  Step  2).  In  this  activity,  you  update  foe 
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CyckN 


program  plan,  including  budgets  and  schedules,  based  on  insights  from 
sponsors  and  issues  of  organizational  readiness.  You  also  develop  a  plan 
for  the  first  three  steps  of  the  next  cycle,  including  conducting  an 
assessment  of  your  organization’s  processes. 

When  updating  the  program  plan  (strategic),  you  use  the  implementation 
analysis  you  performed  in  the  previous  activity.  Review  Progress,  and  as 
much  quantified  information  as  possible  as  the  basis  of  your  changes.  Spe¬ 
cifically,  you  update  the  program  plan,  update  the  budget  and  schedules, 
and  plan  the  first  three  steps  of  the  next  cycle.  Understand  Context, 
Analyze  Risks  and  Select  Strategy,  and  Plan  Improvements. 

•  Program  Plan.  Update  the  program  strategy  and  objectives,  based  on 
the  results  of  the  (^cle  implementation.  Numerous  scenarios  may 
affect  your  program  strategy,  including  the  following: 

-  Tiie  implementation  went  well,  and  the  process  improvements 
should  be  expanded  to  more  of  the  organization  (opening  the  door 
to  institutionalization).  In  this  case,  other  projects  should  follow 
the  plan  used  for  the  pilot  projects,  taking  into  consideration  les¬ 
sons  learned.  Deviations  from  that  plan  may  cause  different 
results. 

-  The  implementation  went  well,  but  minor  changes  should  be  made 
before  institutionalizing  it  throughout  the  organization.  In  this 
case,  the  same  PAT  may  be  tasked  to  make  minor  changes  to  the 
improved  process. 

-  The  organization  should  continue  with  implementation  of  this 
cycle’s  objectives  to  resolve  issues.  This  situation  occurs  when  the 
implementation  was  incomplete  or  experienced  difficulties.  Con¬ 
sider  re-implementing  previous  cycles  and  reconsider  people’s 
assignments. 

-  The  organization  should  re-evaluate  the  entire  situation  since  the 
implementation  was  perceived  to  be  a  failure. 

•  Update  Budget  and  Schedule.  When  updating  the  budget  and  schedule 
for  the  process  improvement  program,  remember  to  allocate  time  and 
resource  contingencies  to  address  such  issues  as  emerging  resistance, 
waning  management  commitment,  and  interference  by  other 
seemingly  independent  changes.  It  is  important  that  the  program  plan 
anticipate  and  plan  for  these  problems. 

•  Plan  Next  Cycle.  Based  on  the  results  of  the  implementation  and  its 
impact  on  the  program  plan,  allocate  resources  and  budget  to  conduct 
the  first  three  steps  of  the  next  cycle. 


8-9 


8.  Steer  Ibward  Success:  Review  and  Update 

Measures 


In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  Time  and  effort  spent  defining  recommendations  and  developing 
program  plans 

•  Size  of  program  plan 

•  Quality  of  program  plan 

•  Number  of  recommendations 


Stop  Criteria 


This  activity  is  complete  when  you  have  deflned  or  updated  all  program 
plans,  as  needed,  based  on  the  results  of  the  current  cycle. 
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8J  COMMIT  TO  PROCEED 


This  activity  begins  in  Step  S,  Review  and  Update. 


Overview 

Your  objective  in  this  activity  is  to  get  all  stakeholders— including  spcnisors, 
chamiHons,  change  agents,  and  process  users— to  conunit  to  {M’ooeed  with  the 
process  improvements  based  on  the  program  plan  you  defined  in  the  Define/ 
Update  Program  Plan  activity.  A  key  part  of  this  activity  is  for  the  sponsors 
to  publicize  their  commitment  across  the  organization,  lb  get  the  commit¬ 
ment  to  proceed,  amfde  oj^rtunity  should  be  provided  fcH*  the  stakeholders 
to  review  and  comment  on  |dans.  Based  on  the  review  results,  you  may 
determine  that  you  need  to  revise  the  {dans. 


Start  CiuTERu 


Start  this  activity  when  you: 

•  Have  developed  a  plan  for  how  the  overall  process  improvement 
program  and  the  first  part  of  the  next  c^cle  should  be  conducted, 
including  a  budget  and  schedule 

•  Understand  who  are  the  stakeholders  for  this  activity 


You  need  to  get  a  commitment  from  the  identified  stakeholders  to  proceed 
with  the  process  improvement  program  based  on  the  program  plan. 

1.  Obtain  Agreement  Erom  Change  Agents,  Champions,  and  Process 
Users.  Seek  agreement  first  from  all  stakeholders  other  than  the  sponsors 
on  the  direction  of  the  process  improvement  program.  The  sponsors  may 
be  reluctant  to  approve  the  plan  until  there  is  buy-in  from  the  other  players 
involved. 


^  SponscK’ 


■pn  Champion 


ft 


IVooess 

User 


Change 

Agent 
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Cycle  1  In  the  first  (^cle,  you  look  for  agreement  only  from  the  diange  agents  and 

champions  who  have  been  working  on  the  initial  improvement  {dan. 

Cycle  2.. In  all  other  cycles,  you  look  for  agreement  from  the  duuige  agents, 
champions,  and  process  users. 

2.  Obtain  Commitment  Fkom  Sponsors.  After  you  have  buy-in  from  all 
champions,  diange  agents,  and  the  process  users,  you  {M’esent  your  plan  to 
the  six>nsors  for  approval  and  commitment  to  proceed.  Your  presentation 
should  include: 

•  Desaiption  of  the  plan,  including  suggested  assignments  or 
res{X)nsibilities  for  the  program 

•  Your  rationale  for  the  plan,  including  justification  for  the  overall 
objectives  of  the  program  (both  long-  and  short-term  benefits) 

•  How  the  execution  of  this  plan  will  im{)act  each  part  of  the 
organization,  es{}ecially  those  grou{}s  related  to  the  sjxsnsors  you  are 
briefing 

•  Estimated  cost  and  time  frame  for  the  implementation  of  this  plan 

Depending  on  your  situation,  you  may  decide  to  stagger  the  presentations, 
targeting  first  those  s{X>nsors  who  are  more  sup{X)rtive,  in  order  to  build 
a  stronger  case  for  those  sponsors  who  are  less  sup{X)rtive. 

In  all  cycles,  you  will  look  for  commitment  to  proceed  with  the  program, 
based  on  your  program  plan.  The  plan  describes  program  strategy,  a  bud¬ 
get  and  schedule,  and  a  specific  plan  for  how  to  proceed  with  the  first  three 
steps  of  the  next  cycle. 

Cycle  1  This  task  is  not  performed  until  adequate  s{x>nsorship  is  established. 

Cycle  2..  In  all  other  cycles,  you  will  seek  commitment  from  the  authorizing  and 
reinforcing  s|X}nsors. 

3.  Publicize  the  Commitment.  After  approving  the  action  plan,  the 
s{X)nsors  need  to  publicize  their  sup{x>rt  and  commitment  throughout 
their  organization  to  keep  everybody  informed,  to  reinforce  the 
im{X}rtance  of  prcx:ess  improvement,  and  to  help  prepare  everybody  for 
the  changes  ahead. 

Cycle  1  This  task  is  not  performed  until  adequate  s{)onsorship  is  established. 


^  Sponsor 
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ft 


Process 
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(Change 
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Measures 


Stop  Criteria 


Assist  the  ^nstm  with  develqHng  a  oommunication  strategy  to  puUidze 
oommitment  Use  the  influence  strategy  created  in  Step  1,  Understand 
Context 


In  order  to  quantify  the  resources  spent  on  process  improvement,  and  to 
improve  the  process  improvement  process  itself,  collect  the  following 
measures: 

•  'nmeandefifortspentreviewingtheidanswithchangeagents,cfaampi(»as, 
and  process  users 

•  Number  of  persons  interacted  with  during  the  review 

•  Hme  and  effort  spent  developing  a  management  presentation 

•  Size  of  the  management  presentation  (e.g.,  number  of  charts) 

•  Quality  of  the  management  presentation 

•  Hme  and  effort  spent  meeting  with  sponsors 

•  Number  of  presentations  to  and  meetings  held  with  sponsors 

•  Time  and  effort  spent  publicizing  the  commitment 

•  Numbo*  of  poscms  to  whom  and  i^acesvdio’e  commitment  was  publicized 


This  activity  is  complete  when: 

•  You  have  secured  conunitment  from  the  sponsor  to  proceed  with  the 
program,  based  on  the  program  plan 

•  The  sponsors  have  publicized  their  commitment  to  the  organization 
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9.  IMPROVING  YOUR  PROCESS  IMPROVEMENT 

PROCESS 


Practice  you  preach. 

Anonymous 


Section  Objectives 

LPtmidegmend 
guiddines  for  improving 
your  organaation's  process 
impmvement  process 

2  SimuruBTze  idurt  an 
organization  would  be  Wee 
that  petfomed  its  process 
improvement  well 


In  contrast  to  Sections  4  through  8  of  this  guidebook,  which  provides  specific, 
step-by-step  guidance  on  how  to  improve  your  process,  this  section  provides 
generic  guidelines  for  imi^ovingyour  organizatiem’s  overall  process  improve¬ 
ment  fM'Ooess.  The  previous  sections  cover  the  launching  oi  a  process  im¬ 
provement  p-ogram  in  considerable  detail;  this  section  emphairizes  aspects 
that  are  commonly  stQl  in  need  of  improvement  after  this  initial  launching. 

Organizations  differ  widely  in  the  ways  they  address  process  improvement: 
some  handle  it  as  stressful  episodes;  others  try  to  leam  firom  ea^  improve¬ 
ment,  but  are  poor  at  applying  any  lessons;  and  still  others  treat  process 
improvement  as  a  ‘‘core  competency”  with  organizational  structures,  pro¬ 
cesses,  and  incentives  aimed  at  maximizing  their  competitive  advantage  in 
this  area.  This  section  covers  variations  among  organizations  and  provides 
strategies  you  can  use  to  improve  yom  own  process  improvement  {V(x«ss. 
It  presumes  that  you  are  seriously  interested  in  improving  your  prcxxss, 
will  attempt  to  do  so  frequently,  and  can  leam  to  organize  and  optimize 
systematically  the  process  improvement  process  and  its  contact  over  these 
many  improvements. 


While  the  earlier  sections  of  this  guidebook  address  improving  the  software 
process,  the  same  princi{des  enunciated  there  apply  to  inqjroving  the  process 
improvement  process.  This  section  applies  these  principles  in  the  larger 
organizational  context  to  the  {rnxxss  imi^ovement  program  itsdf. 


In  this  section,  you  will  leam  how,  with  adaptations  for  your  situation,  to 
change  your  organization's  context  for  process  improvement  (e.g.,  culture, 
infrastructure,  and  external  relationships)  and  your  direct  process  im¬ 
provement  effort  itself  (e.g.,  involvement,  engineering,  and  management). 
A  brief  vision  of  your  ftiture  organization  is  also  provided. 


9.1  ORGANIZATIONAL  CONTEXT 

Instead  of  viewing  the  process  imjxrovement  process  as  an  isolated  set  of 
activities  that  you  initiate  each  time  you  want  to  im|»’Ove  your  process. 
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consider  process  im{»’ovement  to  be  an  ongoing  function  with  a  pennanrat 
set  oi  (M’ganizational  processes  and  relationships. 

From  this  perspective,  process  improvement  involves  the  managed 
exchange  of  information  and  resources,  both  within  your  organization  and 
with  related,  external  organizations.  Figure  9-1  shows  a  number  of 
organizations  and  conditions  that  affect  jn-ocess  improvement,  as  well  as 
the  subsystems  mentioned  in  Section  2. 


Organizatioaal 

Emvonment 


Customers 


Subcontractors 


Competitors 


Contract  I  j 

leammates  I  / 

Strategic  Allies  \  y 

Parent  ' 

Organization 


Strate^ 

Subsystem 


ledinological 

•.^Subsystem 


Improvement 

Sources 


Standards 

Organizations 


Managerial 

Subsystem 


Human/Cultural 

Subsystem 


Structural 

Sub^stem 


^  Consultants 

Rofcssional 

Organizations 


Joint  Ventures  and 
Consortia 


Governments 


Figure  9-1.  Organizational  Context 

When  an  organization  views  process  improvement  as  an  ongoing  function, 
organizational  arrangements  to  handle  technologies  and  process  improve¬ 
ments  may  be  instituted  and  improved.  The  next  sections  provide  guide¬ 
lines  for  these  organizational  arrangements  and  practices  in  the  areas 
shown  in  Figure  9-1: 

•  Strategy 

•  Organizational  culture 

•  Organizational  structures  and  infrastructures 

•  Management 

•  Ibchnology 

•  External  entities  and  relationships 
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Each  sectkm  brie^  descr&es  the  relatioiiship  of  each  area  to  prooeat 
improvanent  and  then  lists  guidelines,  organized  by  topic,  that  will  help 
your  organizatKMi  improve  within  that  area. 


SnuiEcy 

You  improve  your  process  not  for  its  own  sake,  but  for  the  advantages,  both 
immediate  a^  strat^c,  that  improvement  provides.  In  (vder  to  maxi- 
mize  these  advantages,  concentrate  on  process  improvement  ccmsider* 
ations  and  their  role  in  strategic  efforts  and  strategic  and  tactical  {banning. 

Be  wsionaiy  and  aware  of  process  imj^ovuntmt  in  yonr  strat^e  and 
tactical  planning. 

•  Examine  politics  and  international  cranpetitiveness  as  part  of  the 
organizational  context  Consider  not  tmly  potential  global  markets, 
but  global  sources  of  improvement  and  tedmology.  Ensure  that  this 
information  is  received  and  used  by  tlK>se  ndio  need  it 

•  Align  process  imjH’Ovement  efforts  with  the  increasing  scope  oi 
corporate  diaage  goals.  Five  stages,  adapted  from  Venkatraman 
(1991),  are  (1)  localized  improvements  of  increadng  scope,  (2) 
improvement  int^ated  internally  aaoss  organization,  (3)  business 
process  redesign,  (4)  business  network  redes^  including  suppliers, 
customers,  and  others;  and  (5)  business  scope  redefinition,  udiere  new 
I^ocesses  and  technology  are  used  to  change  the  organizaticm’s 
mission,  scope,  markets,  and  ix’oducts. 

•  Use  strat^c,  organization-wide  improvement  efforts  as  the  impetus 
and  resources  to  im]vove  your  inocess  improvement  effort  and  {dan 
future  strategic  {irocess  imfirovement  efforts.  Current  common  strate¬ 
gic  iminovement  efforts  indude  TQM,  the  ISO  9000  series  of  quali^ 
management  ^tem  certification,  and  U.S.  Dejnrtment 
Commerce’s  Mdoolm  Baldridge  Quality  Awards. 

•  Become  more  {voactive  in  {vocess  improvement  by  e^qdoiting  and 
retaining  the  initiative  to  ii^uence  future  events  (e.g.,  influencing 
standards’  directions);  making  quidcer,  better  dedsions  regarding 
improvement  directions  and  use;  and  adiieving  flexibility  to  avoid 
adwrse  events  (e.g.,  developing  an  agile  culture  of  raidd  diange  that 
allows  you  to  enter  new  markets  when  old  markets  fade  away). 

•  Consider  technology  and  {vocess  un{M’ovement  needs,  {dans,  and 
0{}{X)rtunities  in  planning  the  capability  of  your  organization.  Invcdve 
management  and/or  staff  who  provide  resources,  serve  as  sponsors,  or 
promote  process  improvements. 
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Organizational  Culture 

From  an  organizational  viewpoint,  process  im[»’ovement  is  more  than  a 
simple  behavior  that  can  be  called  upon  only  vdien  needed.  It  is  a  com[dez 
set  of  knowledge,  skills,  values,  norms,  behavioral  patterns,  and  ongoing 
activities  that  few  technically  educated  persons  learned  in  sdiool  or  fully 
mastered  early  in  the  wor  lq>lace.  In  order  to  maximize  your  organization’s 
success  at  process  improvement,  you  must  direct  considerable  attention  at 
building  and  nurturing  a  culture  that  supports  and  encourages  the  process. 

Develop  a  culture  that  supports  process  improvement. 

•  Establish  management  commitment  from  the  top  down  to  a  culture 
that  supports  changes  that  lead  to  improvements  in  practices. 

•  Through  a  broad  consensus  process,  establish  an  organizational 
mission  and  organizational  vdues  statements  that  recognize  and 
encourage  ongoing  improvement  and  openness  to  outside  ideas  and 
technology.  Make  sure  your  polides  and  procedures  support  these 
new  statements. 

•  Ensure  that  management  and  staff  understand  the  need  for  process 
improvement  throughout  the  organization,  including  a  long-term  un¬ 
derstanding  of  the  position  of  process  improvement  in  your  business 
strategy. 

•  Examine  the  supporting  values  of  the  organization  examining 
norms  on  risk  management,  openness  to  diange,  beliefs  on  what  is 
needed  to  survive  and  prosper;  staff  empowerment;  commitment  to 
TQM;  customer  orientation;  and  self-image  as  a  leading-edge 
organization. 

•  Use  the  eleven-step  scale  (shown  in  Figure  9-2)  to  determine  local 
cultural  norms  in  handling  risk  or  need  to  change  (Grove  1983; 
Charette  1992;  Redwine  1986;  Sage  1993).  Systematically  raise  the 
level  of  individuals  and  the  organization  on  this  scale. 

•  Hain  management  and  staff  on  process  improvement  prindples  and 
techniques.  This  can  include  training  in  process,  process  improvement 
process,  action  planning,  and  interpersonal  skills  and  human  behavior. 

•  Support  a  culture  of  professionalism  and  lifelong  learning.  Fay  for 
reasonable  professional  memberships,  activities,  and  certification. 
Expect  professionalism  in  all  activities.  Train  and  educate  your 
management  and  staff  in  new  software  engineering-related  skills  and 
knowledge.  Most  computing-related  skills  and  knowledge  have  a 
half-life  of  five  years  or  less,  and  requires  continual  training  and 
education  of  software  management  and  staff. 
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lagure  9*2.  Eleven-Step  Scale  for  How  Organizatioas  React  to  Risks  or  Need  to  Improve 


Organizational  Structures  and  Infrastructures 

Your  organizational  structure  and  infrastructure  must  change  to 
incorporate  new  improvement  strategies  and  cultural  practices.  These 
changes  may  involve  new  functions  and  groups  or  new  relationships  among 
those  that  already  enst. 

Ensure  that  organizational  stmctnres  exist  to  support  process 
improvement. 

•  Use  your  human  resource  department  to  ensure  availability  of 
otpertise,  skills,  and  training  in  process  and  process  improvement. 

•  Create  a  tedmology  organization  that  identifies  and  tests  new 
technologies  and  helps  bring  them  into  the  organization.  Consider 
carefully  its  relationship  with  the  rest  of  the  organization,  staffing 
(induding  rotation),  resources,  duties  (to  identify,  not  invent), 
organizational  placement,  and  permanence. 

•  Develop  a  permanent  internal  training  capability  to  develop  and/or 
customize  training  materials  rapidly,  deliver  them  successfully,  and 
maintain  ongoing  training  support.  This  requires  spedalized  «q)ertise 
in  professional  training  and  instructional  design. 

•  Use  a  process  improvement  group,  such  as  the  PG,  to  fadlitate  the 
introduction  of  improvements  and  new  tedmology. 
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•  Have  an  SC,  induding  line  managers,  that  possesses  the  resources  and 
authority  needed  for  imin-ovement. 

Etasnie  that  infrastructure  mechanisms  exist  to  support  process 

improvement. 

•  Develop  measurement  programs  that  establish  baselines  and  measure 
prt^ess  toward  process  improvement  Refer  to  Software  Measurement 
Guidebook  (Software  Productivity  Consortium  19^)  for  information 
on  how  to  set  up  a  measurement  program. 

•  Develop  guidelines  for  institutionalizing  a  process  (e.g.,  how  to  revise 
budgeting,  infrastructure  procedures,  and  job  descriptions). 

•  Coordinate  and  refine  the  roles  in  process  improvement  for  sudi  areas 
as  technical  support,  configuration  management,  the  technical  library, 
and  purchasing. 

•  Create  information  repositories  of  previous  process  improvement 
experiences  to  assess  Ae  impact  of  a  change  and  to  allow  you  to 
improve  your  process  continuously  by  learning  from  past  mistakes. 
Capture  Ae  "folklore**  of  managers  ai^  staff  who  "tell  their  story**  and 
a  more  objective,  common  set  of  elements,  sudi  as  what  improvement 
medianisms  were  used,  the  role  of  users,  and  the  dedsion-making 
process.  Information  on  past  process  improvement  otperiences  can 
help  you  plan  and  predict  future  improvements.  Information  on  plans 
can  allow  projects  to  integrate  their  improvement  approaches.  The 
repository  need  not  be  in  one  central  place,  but  it  should  be  easy  to 
access. 

•  Migrate  toward  open  hardware  and  software  environments  that 
support  addition  and/or  modification  of  technologies. 

•  Int^ate  the  organization*s  process  improvement  process  with  other 
organization-wide  processes  (e.g.,  TQM)  and  with  any  strategic  jdanning 
processes  or  groups. 

•  Establish  an  organizational  assessment  and  analysis  capadty,  and  use 
it  regularly.  This  should  help  you  understand  where  your  organization 
stands  in  regard  to  process,  technology,  and  other  changes. 

•  Be  alert  to  and  consider  ways  that  your  organization  can  distribute 
expertise  among  staff,  thereby  redudng  reliance  on  individual 
specialists  while  at  the  same  time  increasing  flexibili^.  This  might 
include  changing  the  extent  and  speed  of  information  flow,  flow  of 
expertise  and  people,  ease  of  organizational  learning  and 
improvement,  and  advocacy  for  unbiased  evaluation  methods  and 
multidisciplinary  knowledge. 
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•  Develop  (vocess  imi^ovement  awaren^  medianisms  (tedmical 
libraries,  network  services,  outside  database/library  services,  domain 
eiqMrts,  bendunarking,  aiKl  tedmology  receptor  organizations)  that 
help  staff  identify  im|»ovements. 


Management 

The  management  of  the  process  improvement  effort  involves  the  full  range 
of  management  issues.  Many  of  the  points  made  elsevriiere  in  this  section 
have  management  components.  The  guidelines  here  directly  address 
managers  of  process  improvement  efforts. 

Be  an  example  of  a  well-ran  effort. 

•  Set  explidt,  realistic  objectives  and  goals,  both  near-  and  longer-term. 

•  Model  desired  process  behavior.  While  one  cannot  reasonably  eqiect 
your  process  improvement  program  to  be  mudi  better  organized  and 
executed  than  your  projects,  strive  to  model  the  next  round  of  improve¬ 
ments  desired  of  such  projects.  For  example,  if  you  aq)ect  projects  to 
use  sound  estimating  prot^ures,  theu  the  process  improvement  pro¬ 
gram  should  use  them;  or,  if  you  are  aiming  toward  having  a  defined 
software  process,  then  the  process  improvement  program  should 
define  its  process  first. 

•  Build  a  culture  within  the  process  program  that  dimbs  the  eleven-step 
scale  (Figure  9-2)  ahead  of  the  rest  of  the  organization. 

•  Explidtly  manage  imcertainty  and  risks.  Do  not  allow  anyone’s  n^pic 
concern  for  ROI  guarantees  to  divert  you  fi’om  doing  the  ri^t  thing. 
Process  improvement  economics  is  in  its  infancy.  Though  management 
imderstands  the  need  to  be  successful  at  process  improvement,  a  de¬ 
tailed  understanding  of  the  costs  versus  the  benefits  of  foUowing  a 
defined  process  improvement  process  does  not  yet  exist. 

•  Conduct  your  own  otplidt  process  improvement  effort 
Be  customer  driven. 

•  Listen  to  process  users  and  the  SC.  Consider  the  agoi^,  the  mon^, 
and  the  needs  of  the  process  users  and  their  customers  in  deddingvriiat 
to  do.  Motivated  process  improvement  users  are  key  to  success. 

•  InCTease  sponsor  and  management  commitment  and  enthusiasm  by 
building  increasingly  open,  warm,  ongoing  relationships  with  more  k^ 
persons. 
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•  Rotate  process  users  through  the  process  imi»^ovement  program  and 
teams. 

•  Establish  validated  requirements  for  your  process  definition  efforts. 

•  Measure  diffusion,  success,  and  satisfaction. 

Integrate  process  improvement. 

•  Involve  yourself  in  all  related  fdanning  (including  budgeting)  and  with 
similar  initiatives. 

•  Increase  awareness,  coordination,  and  integration  among  i^^ocess 
improvement  and  technology  efforts  throughout  the  organization. 

•  Ensure  that  the  process  improvement  program’s  own  processes 
integrate  smoothly  with  other  organizational  processes. 


Technology 


The  technological  subitem  covers  issues  such  as:  Are  the  jvocesses  used  to 
transform  inputs  into  outputs  standardized  and  institutionalized?  Do  the  pro¬ 
cesses  rigidify  operations,  or  are  tht^  flexible?  What  types  of  technologies  are 
being  used?  InstitutionalizaticHi  is  die  extent  to  Miicfa  the  use  of  the  process 
is  routine,  widespread,  and  embodied  in  the  organization’s  governance 
mechanisms. 

In  your  process  engineering,  use  the  best  practices  and  ideas  firom 
systems  engineering  organizational  development,  process  improvement, 
user,  and  other  communities. 

•  Ihke  inaeasing  advantage  of  the  existing  expertise,  both  inside  and 
outside  your  organization,  to  improve  your  state  of  practice  in  process 
engineering.  Stcl^txxss  Definition  ondModelingGuidebookfSoftwdic 
Productivity  Consortium  1992a)  and  Process  Engineering  With  the 
Evolutionary  Spiral  Process  Model  (Software  Productivity  Consortium 
1993b). 

•  Insist  on  professionalism  in  process  engineering.  Pay  for  reasonable 
professional  memberships,  activities,  and  certification.  Expect  knowl¬ 
edge  of  limitations,  combined  with  professional  networking  and  paid 
assistance,  to  find  answers. 

•  Support  learning.  Drain  and  educate  your  process  management  and 
staff  in  new  process  engineering-related  sldlls  and  knowledge.  Most 
software  process  kno^edge  and  skill  has  an  even  shorter  half-life  than 
regular  computing  knowledge;  this  requires  continual  study,  training, 
and  education. 
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•  Emulate  the  best  involvement  medumisnu  in  use  in  your  organization 
(e.g..  Integrated  Product  Ibams  (IFI^)  or  concurrent  engineering 
teams). 

•  Pay  attention  to  process  requirements  and  architecture. 

•  Ensure  that  processes  result  in  meaningful,  interesting,  and  enjoyable 
jobs. 

•  Use  process  (re)design  expertise  to  improve  process  speed, 
dependabiliQr,  cost,  and  resulting  customer  satisfaction. 

•  Cultivate  the  persons  performing  the  process  to  become  your  biggest 
source  for  improvement  suggestions— then  use  them. 

Stay  on  top  of  new  process  developments. 

•  Access  and  digest  relevant  periodicals,  market  reports,  and  government 
studies.  Subsoibe  to  services,  databases,  and  analysis  groups. 

•  Use  traditional  and  nondirectional,  and  local  and  global  sotirces  for 
new  processes  and  tedmology.  Ifaditional  sources  include  consulting 
firms,  colleagues,  literature,  seminars,  internal  research  and  develop¬ 
ment  (R&D)  laboratories,  universities,  computer  manufacturers,  tool 
vendors,  and  meeting.  Less  traditional,  but  sometimes  even  more 
effective,  sources  indude  joint  ventures,  consortium  me  bership, 
federally  funded  R&D  centers,  competitors,  suppliers,  and  customers. 

•  Partidpate  in  or  tradt  appropriate  standards  projects. 

Exploit  automation. 

•  Use  office  automation  to  manage  and  commum’cate. 

•  Use  automation  to  support  process  definition  and  modeling.  See 
Process  Definition  and  Modeling  Guidebook  (Software  Productivity 
Consortium  1992a). 

•  Evaluate  and  pioneer  process  enactment  or  workflow  management 
tools  within  the  process  improvement  effort. 

Integrate  software-related  processes. 

•  Ensure  that  software  processes  and  methods  integrate  well. 

•  Integrate  software  processes  with  related  processes,  such  as  systems 
engineering  process  and  marketing  process. 
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Institutionalize  pnxxss  improvement. 

•  Define  the  process  improvement  process  and  evolve  the  definition. 

•  Achieve  a  workforce  skilled  in  its  use. 

•  Embody  in  organizational  governance  mechanisms,  such  as  policies, 
procedures,  measurements,  reports,  reviews,  assessments,  and  audits. 

•  Use  universally  (esKept  for  eq^dt,  managed,  purposeful  f^otdianges). 

•  Incorporate  in  initial  persoimel  indoctrination  and  training,  and  other 
mechanisms  of  acculturation. 

•  Reinforce  to  prevent  slowly  fading  away. 


External  Enttiies  and  RsLATioNsmps 

In  order  for  your  organization  to  be  a  permanent  leader  in  process 

improvement,  it  must  develop  stable  and  long-term  relationships  with 

important  external  organizations,  including  your  customers,  suppliers 

(e.g.,  vendors  and  consultants),  and  industrial  peers. 

Ensure  strong  and  improving  relationships  with  external  organizations. 

•  Encourage  staff,  user,  supplier,  and  customer  involvement  in  dedsions 
that  affect  them. 

•  Attempt  to  establish  relationships  to  facilitate  codesign  of  processes 
by  supplier-customer  pairs  or  chains  with  your  submntractors  and 
clients. 

•  Fbrm  ongoing  relationships  with  select  process  improvement  and 
technology  sources.  This  can  take  such  forms  as  industrial  liaison  rela¬ 
tionships  with  universities,  contracts,  joint  ventures,  consortia,  period¬ 
ic  benchmarking,  strategic  alliances,  investment,  or  cross-ownership. 
Ongoing  relationships  will  help  fadlitate  transfer,  give  you  advance  in¬ 
sight  and  influence  on  how  new  processes  might  fit  into  your  environ¬ 
ment,  and  promote  ongoing  support  for  the  transfer  from  the  source. 

•  Provide  a  vehicle  for  systematically  asking  customers  and  suppliers 
about  their  immediate  and  expected  future  process  and  technology 
needs  and  changes. 

•  Carefully  select  and  form  a  relationship  with  assessor  organization(s) 
and  personnel  that  can  come  to  know  your  organization  and  approach 
to  improvement. 


9-10 


•  FItod  ways  (e^inchgtiysurv^baichmaildqg,  vials,  busmessii^ 
to  compare  yc>ur  (x:g9iuzatkm's  {xooess  and  in)oess  improwmi^ 
to  that  oi  your  oompetittxs. 

9  J  WHAT  YOUR  ORGANIZATION’S  FUTURE  SHOULD  BE 

Assuming  that  all  or  most  of  the  preceding  suggested  guidelines  have  been 
followed  to  oondusion,  you  will  work  in  a  new  type  of  organization.  This 
section  outlines  a  vision  of  what  it  should  be  like,  covering  the  same  six 
areas  as  the  prior  section.  (Steele  [1989]  offers  a  somewhat  similar  view  of 
the  ''technologically  effective  organization.”) 

•  Strat^.  The  organization  will  take  an  e]q>licit  systems  view  of  process 
and  process  improvement  in  the  context  of  the  organization  and  its  ob¬ 
jectives,  strategies,  and  environment.  Likewise,  recognition  of  the  im¬ 
plications  of  technology  and  technology  diange  will  be  pervasive  in  the 
management  and  operation  of  the  enterprise.  The  open  computing  en¬ 
vironment,  people,  organization,  processes,  products,  and  external 
relationships  will  evolve  together  to  achieve  continuing  overall 
improvement  and  success. 

Your  organization  will  take  a  global  approach  to  the  dianging  nature 
of  competition,  both  in  the  players  and  &e  basis  for  competition.  Your 
organization  will  re(X}gnize  in  many  markets  the  basis  of  competition 
shifting  toward  quality,  total  customer  satisfaction,  speed  to  market, 
solutions  rather  than  means,  custom  fit  at  mass-market  prices,  custom¬ 
er  delight,  technical  compatibility,  corporate  virtue,  and  long-term 
relationships. 

•  OrgamazttffiiafCu&ure.  Yourorganizationwillchangeproactivetyatarate 
that  will  be  uncomfortable,  but  not  debilitating.  No  process  or  tedmology 
will  be  totally  sacred  or  undiangeable.  The  rate  of  diange  will  be  fast 
enough  to  respond  to,  and  even  shape,  the  external  considerations  that 
necessitate  diange. 

All  parts  of  the  organization  will  be  improvement-oriented,  including 
enterprise-wide  TQM  efforts,  which  will  result  in  relentless  removal 
of  the  causes  of  and  opportunities  for  defects,  as  well  as  improvements 
of  all  sorts,  including  tedmological  ones.  TQM-style  bendimarking 
will  help  many  organization  functions  compare  themselves  to  the  best- 
known  state-of-the-art  practice. 

•  Structure  and  It^astructure.  While  organizational  arrangements  may 
vary,  the  process  expertise  and  functions  will  be  offidal,  effective,  effi- 
dent,  and  improving-Hvorld  class.  IVaining,  support,  and  other  infira- 
structures  will  exist  as  part  of  an  institutionalize  approach  to  process 
improvement.  Human  resources  and  careers  will  be  managed  sudi 
that  selection,  education  and  training,  assignments,  and  departures 
result  in  the  needed  skill  mix  at  the  time  needed. 
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•  Management.  Your  organization  will  be  self-aware,  using  both  an 
institutionalized  measurement  program  and  periodic  self- 
assessments,  in  both  technical  and  nontechnical  areas.  It  will  have 
defined  explicit  success  factors  and  will  report  on  levels  of  {M^ocess,  and 
technology  use  and  mastery.  It  will  be  able  to  tell  incompetence  or 
error  from  bad  luck — and  act  accordingly. 

Process  and  other  risks  will  be  managed  and  mitigated.  This  will  be 
part  of  dealing  with  the  ongoing  tensions  between  exploiting  current 
capabilities  and  advantages,  and  creating  new  ones-^e  mmdi  be¬ 
tween  doing  something  the  old  way,  versus  spending  time  and  mon^ 
to  learn  and  master  a  new  way.  Multiple  alternatives  will  be  vigorously 
sought  and  objectively  selected  among. 

•  Technology.  Recently  begun  projects  will  use  a  modem,  reasonably 
integrated  set  of  tedmologies  and  processes  tailored  from  the 
organization’s  process  guidance.  Most  of  these  projects  will  try 
something  new,  however,  in  a  stage  of  the  development  process  as  part 
of  the  organization’s  systematic  and  sanctioned  exploration  and 
learning  activities.  Older  projects  will  upgrade  their  process  and 
technology  more  slowly,  but  will  follow  defined  management  and 
technical  processes.  Process  improvement  and  technology  awareness, 
exploration,  and  transfer  will  be  explidt  and  will  follow  defined 
processes  and  methods  integrated  into  your  organization’s  processes 
and  methods,  particularly  for  TQM  and  systems  engineering,  but  also 
for  the  full  set  of  the  enterprise’s  processes. 

Knowledge  and  skills  will  flow  rapidly  and  ^tematically  into  and 
through  ^e  organization  to  all  the  places  they  are  needed  or  usable. 
While  not  neglecting  mastery  and  continual  improvement  of  present 
processes,  the  organization  will  look  multiple  technology  generations 
ahead  for  relevant  technologies:  product,  process,  and  informational. 

•  External  Entities  and  Relationships.  The  world  that  you  and  your 
organization  live  in  will  be  an  accelerating,  increasingly  exdting,  and 
potentially  hazardous  one.  In  your  well-organi^  enterprise, 
however,  the  interest  and  exdtement  of  all  concerned  (manager, 
technologist,  and  user)  in  engaging  the  world  and  successfully 
advandng  the  process  and  technology  used  in  your  organization  will 
exceed  any  discomfort  involved. 

The  organization  will  know  about  competitors,  both  current  and 
potential,  and  will  produce  objective  comparisons.  It  will  explidtly 
exploit  process  for  enhanced  competitiveness. 

Key  technical  personnel  and  management  will  have  active  external 
interactions — ^particularly  with  customers,  but  also  with  sources  of 
improvements,  peers  in  your  profession  and  industry,  subcontractors. 
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government,  and  academe.  Attention  and  interat^on  will  not  be 
parodiial  in  terms  of  organization,  geography,  or  disci|;dine. 

Realistic  decisions  will  be  made  on  in-house  process  improvement 
development  versus  obtaining  it  from  outside.  Nondisclosure 
agreements,  alliances,  and  joint  ventmes  sudi  as  consortia  will  be 
formed  with  customers,  teammates,  and/or  suppliers  to  understand, 
forecast,  and  achieve  the  technology  (and  other  factors)  needed  for 
success.  Your  organization  will  have  learned  how  to  manage  and 
practice  these  types  of  collaboration. 


93  CONCLUSION 


Essentially,  this  section  focuses  on  how  your  organization’s  process 
improvement  program  can  routinely  perform  better  the  business  of 
process  improvement  and  offers  a  vision  of  where  that  should  lead. 
Moving  to  this  vision,  however,  can  only  be  done  incrementally.  You  can 
best  follow  the  guidelines  incrementally  by  adopting  the  underlying 
management  approach  first  outlined  in  Section  3  and  applying  it  to  this 
section’s  larger  context. 

Improvements  in  your  process  improvement  program  should  be  mutually 
reinforcing,  with  improvements  in  your  strategy,  culture,  and  structure 
that  ensure  thatyou  aeate  supportive  internal  and  external  arrangements, 
policies,  procedures,  and  practices.  Altogether,  obviously,  this  involves  a 
major  process  of  organizational  development  that  serves  both  to  create  a 
more  change-oriented  organization  and  to  make  each  process  improve¬ 
ment  more  integrated  with  the  organization’s  vision  and  culture — and 
more  routine. 
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APPENDIX  A.  CHECKLISTS  FOR  APPLYING  THE 
PROCESS  IMPROVEMENT  PROCESS 


Apptndbc  (X^ecthe 

Rovide  diecklists  to 
guide  you  thrmgfi  the 
inqdementation  cfthe 
process  improvement 
process 


The  guidance  that  is  provided  in  Sections  4  through  8  presents  the  process 
improvement  process  from  a  step/acdvityAask  perspective.  The  guidance 
is  ordered  by  step,  activity,  and  task,  with  the  guidwce  tailored  for  each 
cycle  (1,2,  and  Nf)  within  each  task.  Cycle  N  represents  all  cydes  following 
the  first  two. 

This  appendix  provides  you  with  a  different  view  into  the  process 
improvement  process.  Instead  of  ordering  by  step/activity/task,  the 
ordering  is  presented  ty  cycle.  Specifically,  for  eadi  cycle  (1, 2,  and  N),  this 
appendix  provides  a  cheddist  that  outlines  the  spedfic  tasks  you  perform 
in  each  cycle.  These  checklists  are  based  on  the  overall  strategy  for  process 
improvement  as  desaibed  in  Section  3.3,  Locating  Yourself  in  the  ^ocess. 

Tkble  A-1  provides  the  checklist  for  Cyclel;  "Bible  A-2  provides  the 
checklist  for  Cyde  2;  and  Ikble  A-3  provides  the  cheddist  for  Cyde  N. 
Each  table  includes  a  column  for  additional  comments  you  may  wish  to 
note  during  the  execution  of  the  tasks. 
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IkbleA-1.  Cyde  1  Iksks  Cheddist 


Cydellksks 


1.  Step  1:  Understand  Context 

Activity:  Build  Sponsorship  and  Foundation 

□  Understand  the  implementation  dimate  and  organizational 
readiness 

□  Prepare  and  execute  influence  strategy 
Acthi^  Deflne  Improvement  Strategies 

□  Define  objectives 

□  Identify  alternatives 

□  Identify  constraints 
Activify:  Review  Context 

□  Obtain  agreement  from  change  agents,  champions,  and 
process  users 

2.  Step  2:  Analyze  Risks  and  Select  Strategy 
Activity:  Analyze  and  Resolve  Risks 

□  Identify  and  analyze  risks 

□  Review  risk  analysis 

□  Evaluate  and  plan  risk  mitigation 

□  Commit  to  the  risk  management  plan 

□  Execute  risk  management  plan 
Activity:  Select  Improvement  Strategy 

O  Select  a  process  improvement  program  and/or  (yde  strategy 
Activify:  Commit  to  Strategy 

□  Obtain  agreement  from  change  agents,  champions,  process 
users 

3.  Step  3:  Plan  Improvements 

No  activities  or  tasks  to  perform  in  Cfyde  1 

4.  Step  4:  Implement  Improvements 

No  activities  or  tasks  to  perform  in  Cyde  1 

5.  Step  5:  Review  and  Update 
Activify:  Define  Program  Plan 

O  Define  recommendations  and  develop  program  plans 


Additional  Conwents 
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lkbleA-2.  Cyde 2 Iksks Cbeddist 


Ikble  A>2,  ocmdaned 


CydelTksks 


4.  Step  4:  Implement  Impiovmnents 

No  activities  to  perfonn  in  Qde  2 

5.  Step  5:  Review  and  Update 
Activi^  Update  Program  Plan 

□  Define  recommendations  and  update  program  {dans 
Activity:  Commit  to  Proceed 

□  Obtain  agreement  from  change  agents,  champions,  and 
process  users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 


Additional  Comscnts 
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lkUeA-3.  Cycte  N  Tasks  Cheddist 


Cycle  N  Tasks 


1.  Step  1:  Uodeistand  Context 

Activi^  Build  Sponsorship  and  Foundation 

□  Understand  the  implementation  dimate  and  organizational 
readiness 

□  Repare  and  execute  influence  strategy 

□  Demonstrate  sponsorship  and  commitment 

□  Form  a  Steering  Committee 

□  EstaUish  a  Process  Group 

Activity:  DefineAJpdate  Improvement  Strategies 

□  Define/update  objectives 

□  Identify  alternatives 

□  Identify  constraints 
Activity:  AssessAJnderstand  Process 

□  Assess/understand  your  organization’s  current  process 

□  Identify  recommendations  for  improvement 

□  Develop  a  findings  and  recommendations  report 

□  Present  the  recommendations 
Activity:  Review  Context 

□  Obtain  agreement  from  change  agents,  champions,  and 
process  users 

□  Obtain  approval  from  sponsors 

□  Publicize  commitment 

2.  Step  2:  Analyze  Risks  and  Select  Strategy 
Actmfy:  Anafyze  and  Resolve  Risks 

n  Identify  and  analyze  risks 

□  Review  risk  analysis 

□  Evaluate  and  plan  risk  mitigation 

□  Conunit  to  the  risk  management  plan 

□  Execute  risk  management  plan 
Activity:  Select  Improvement  Strategy 

□  Select  a  process  improvement  program  and/or  cyde  strategy 


Additioiial  Comincnts 
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Cycle  N  Iksks  |  Additkmal  CoBuseBts 

Activity:  Commit  to  Strategy 

n  Obtain  agreement  from  change  agents,  champions,  and 
process  users 

□  Obtain  approval  from  sponsors 

□  Publicize  commitment 

3.  Step  3:  Plan  Improvements 
Activity:  DeOneAJpdate  Action  Plan 

□  EstaUish  a  PAT  toi  eadi  major  area  of  improvement 

□  Ihsk  each  PAT  to  develop  a  tactical  {dan 
D  Task  the  SC  to  develop  a  tactical  plan 

□  Task  the  PG  to  develop  a  tactical  plan 

□  Incorporate  each  tactical  plan  into  the  action  plan 

□  Identify  budget  and  staffing 

□  Develop  measures  of  success 

□  Analyze  risks  associated  with  the  action  plan 
n  Finalize  the  action  plan 

Activity:  Commit  to  Action  Han 

□  Obtain  agreement  &om  change  agents,  champions,  and 
process  users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 

4.  Step  4:  Implement  Improvements 
Activity:  Implement 

□  Implement  the  action  plan 
Actmty:  Manage  and  Monitor 

□  Manage  the  implementation 

□  Gather  implementation  data 

□  Support  the  PAI^ 

□  Anafyze  risks  associated  with  implementation 

□  Manage  resistance  to  change 

□  Reinforce  sponsor  commitment 
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Cyde  N  Iksks 


Activity;  Review  Process  Improvements 

□  Collect  and  review  process  assets 

□  Collect  and  document  lessons  learned 
5.  Step  5:  Review  and  Update 

Activity:  Review  Ingress 

□  Compare  implementation  data  to  objectives 

□  Review  lessons  learned 

□  Baseline  process  assets 
Activity:  Update  Program  Plan 

□  Define  recommendations  and  update  program  plans 
Activity:  Commit  to  Proceed 

□  Obtain  agreement  from  change  agents,  champions,  and 
process  users 

□  Obtain  commitment  from  sponsors 

□  Publicize  commitment 


Additional  Comments 


APPENDIX  B.  SOFTWARE  PROCESS 
ASSESSMENT  METHODS 


Appendix  Objective 

Describe  methods  that 
support  the  activity 
AssesslUrulerstand  the 
Process 


This  appendix  enumerates  and  describes  three  software  process  assesanent 
mediods  that  support  the  Assess/Understand  the  Process  activity  presented 
in  Section  4.  The  methods  covered  in  this  section  are: 

•  SPAbytheSEI 

•  Process  Advisor  by  R.S.  Pressman  &.  Associates,  Inc. 

•  ISO  9000  by  the  International  Organization  for  Standardization 
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B.1  SOFTWARE  PROCESS  ASSESSMENT  METHOD 

The  SEI,  a  federally  funded  research  and  development  center  of  the 
Department  of  Defense,  has  refined  a  method  for  assessing  an 
organizatiou  ^  process  maturity  and  an  underlying  framework,  the  CMM. 

The  Software  Productivity  Consortium  is  a  licensed  vendor  of  the  SPA 
method. 

Capability  Maturity  Model 

Most  engineers  and  managers  are  quick  to  identify  problems  within  their 
organization,  but  get  mired  in  heated  debates  about  what  improvements 
to  make  and  in  which  order.  For  those  people  looking  for  lasting  results, 
not  just  quick  fixes,  it  is  best  to  proceed  in  an  evolutionary  maimer,  with 
successive  stages  building  on  previous  ones. 


Levels  of  Software  Process  Maturity 

The  CMM  is  a  conceptual  framework,  based  on  state-of-the-art  software 
practices,  that  guides  organizations  through  five  levels  of  process  maturity, 
supporting  the  premise  that  continuous  improvement  occurs  in  small,  evo¬ 
lutionary  steps  (Imai  1986).The  CMM  framework  allows  organizations  to 
characterize  their  process  maturity,  establish  strategic  goals  for  process 
improvement,  set  priorities  for  immediate  actions,  and  strive  to  establish 
and  achieve  a  culture  of  software  engineering  excellence.  Figure  B-1  shows 
the  five  levels  of  maturity. 


Figure  B-1.  Software  PJooess  Maturity  Levels 
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Software  process  maturity  is  the  degree  to  whidi  a  software  process  is 
explicitly  and  effectively  defined,  managed,  measured,  and  controlled 
(Imai  1986).  The  implication  of  software  process  maturity  is  that 
organizations  can  improve  their  software  {vocess  fi'om  one  that  is  ad  hoc 
and  chaotic  to  one  that  is  disciplined  and  consistent. 

Immature  organizations  constantly  operate  in  a  fire-fighting,  reactionary 
mode.  They  rarely  meet  schedules  or  budgets  since  they  lade  suffident 
management  planning  of  and  visibility  into  software  development  activi¬ 
ties.  Lacking  an  organization-wide  software  process,  immature  organiza¬ 
tions  have  no  basis  to  predict  or  measure  quality  or  to  guide  process 
improvement  activities.  Success,  when  it  occurs,  depends  on  the  heroic  ef¬ 
forts  of  individuals.  Operating  an  organization  in  this  manner  leads  to  low 
employee  morale  and  high  burnout,  possibly  leading  in  turn  to  high  attri¬ 
tion  rates.  The  most  costly  effect  may  be  the  inability  to  meet  customers’ 
expectations. 

Mature  organizations  have  the  capability  to  manage  software  development 
and  maintenance  activities  successfully  since  these  activities  are  based  on  an 
organization-wide  software  process.  Roles  and  responsibilities  within  the 
software  process  are  clearly  defined,  thus  facilitating  better  communications 
among  staff.  Activities  within  the  software  process  are  measurable,  providing 
a  way  to  improve  predictability  of  sdiedules,  cost,  and  quality.  Management 
can  see  progress  and  understand  the  effects  of  jx'oposed  changes,  ^ch 
results  in  informed  dedsion-maldng. 

Organizations  at  the  Initial  Level  typically  do  not  have  sound  management 
practices  in  place,  thereby  compromising  the  benefits  of  any  software  engi¬ 
neering  practices  that  may  exist.  When  a  oisis  occurs,  any  hint  of  a  formal 
process  is  abandoned.  The  successes  that  do  occur  in  organizations  at  the  Ini¬ 
tial  Level  are  typically  due  to  the  efforts  of  dedicated  individuals,  without 
whose  efforts  the  organization  would  founder. 

Organizations  at  the  Repeatable  Level  have  established  policies  and 
procedures  for  managing  a  software  project  Realistic  project  schedules  are 
based  on  past  experiences  and  project  requirements.  Project  costs,  sdiedules, 
and  functionality  are  tracked.  Level  2  organizations  typically  have  a 
disciplined  project  management  process  that  provides  a  basis  for  f^oject 
planning  and  tracking. 

At  the  Defined  Level,  an  organization-wide  standard  software  process  exists 
for  developing  and  maintaining  software.  This  process  is  documented  and 
covers  both  software  engineering  and  management  activities.  Level  3 
organizations  have  a  dedicated  team  focused  on  software  process  activities. 
Projects  may  tailor  the  organization’s  software  process  to  account  for 
project-specific  characteristics.  Level  3  organizations  are  typically  stable  and 
consistent  due  to  the  effectiveness  of  the  underlying  organization-wide 
software  process. 
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At  the  Managed  Level,  organizations  begin  to  improve  the  predictability 
of  projects  by  setting  measurable  quality  goals  for  both  the  product  and 
process.  These  measurements  provide  the  organization  with  insights  into 
better  control  of  process  variations.  Level  4  organizations  are  b^t  called 
predictable  because  of  rigorous  process  measurement,  and  they  operate 
within  statistical  control  limits. 

At  the  Optimizing  Level,  organizations  focus  on  ocmtinually  improving  the 
efiSdency  of  their  software  {M-ocess.  Defects  in  both  the  fx-oduct  and  the  pro¬ 
cess  are  prevented,  aiKl  opportunities  for  technology  innovations  are  identi¬ 
fied  and  transferred  throughout  the  organization.  Level  5  organizations 
thrive  on  the  culture  of  controlled  change  and  imf^ovement 

Software  Process  Assessment  Method 

The  SPA  is  the  primary  activiQr  for  understanding  an  organization’s  software 
capability.  The  assessment  activity  is  accomplished  by  performing  four 
separate  tasks: 

•  Assessment  team  selection 

•  Assessment  team  training 

•  Assessment  partidpants  briefing  (APB) 

•  On-site  period  (OSP) 


Assessment  Team  Selection 

The  general  criterion  for  selecting  team  members  is  that  they  should  have 
a  minimum  of  10  years  of  experience  in  one  or  more  of  the  following: 

•  Software  development 

•  Project  management 

•  Quality  assurance  (QA) 

•  Testing 

•  Configuration  management 

•  PG  experience 

The  individuals  selected  should  be  well  respected  in  the  organization  and 
be  credible  with  management.  One  ground  rule  should  be  that  the 
individual  is  not  currently  responsible  for  managing  a  project  or  personnel 
that  will  be  included  in  the  discussion  sessions  of  the  assessments.  This 
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relationship  could  hinder  the  flow  of  information.  The  Assessment  Ifeam 
Leader  (AFL)  should  have  the  same  qualifications,  plus  have  esqierienoe 
in  making  presentations  to  peers  and  management.  All  members  of  the 
assessment  team  should  be  team  players  and  should  be  interested  in 
helping  the  organization  improve  its  capabiliQ^  to  develop  software. 


Assessment  Team  Training 

Taining  is  Qrpically  conducted  by  a  team  of  two  professionals,  both  of  whom 
have  extensive  SEl  assessment  eqierience,  during  a  three-day  perkxL  l^pi- 
cally,  the  assessment  training  is  fac^tated  by  an  individual  authorized  to  letul 
an  SPA. 

The  specific  objectives  of  the  SPA  training  course  are  to: 

•  Begin  team  building  within  the  assessment  team 

•  Provide  understanding  of  the  concept  of  a  software  engineering  process 

•  Provide  understanding  of  the  framework  of  the  SEI  assessment  process 

•  Provide  hands-on  experience  in  the  assessment  process  through  role 
playing  using  a  detailed  case  study 

•  Provide  a  practical  introduction  of  the  SEI  CMM  into  the  assessment 
process 

Taining  follows  an  agenda  of  lecture  and  student  participation  exercises. 
The  training  emphasizes  the  activities  that  are  the  most  difficult  to 
perform  during  the  actual  assessment.  This  is  especially  true  of  the  use  of 
role  plays  for  project  leader  (PL)  discussions  and  functional  area 
representative  (FAR)  discussions,  which  are  an  important  part  of  the 
assessment. 

Ibward  the  end  of  training,  planning  for  the  subsequent  APB  and  OSP 
tasks  is  conducted.  The  planning  involves: 

•  Defining  the  organization  to  be  assessed 

•  Defining  a  project  within  that  organization 

•  Selecting  four  to  six  projects  to  be  assessed 

•  Determim'ng  the  characteristics  of  a  PL  within  the  organization 

•  Defining  requirements  of  and  selecting  the  FAR  groups 

•  Assigning  the  role  of  ATL  and  team  coordinator 
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•  Describing  the  related  logistics  that  need  to  be  considered  for  an 
assessment 

•  Outlining  the  structure  and  contents  of  the  APB 

The  list  of  candidate  projects  typically  should  include  at  least  five  to  seven 
projects,  lypical  considerations  indude: 

•  Size  of  project 

•  Assigned  PL 

•  Length  of  project 

•  Number  of  developers  on  the  project 

•  Current  life-cyde  phase  that  the  project  is  working  on 

•  Application  domain 


Assessment  Participants  Briefing 

The  APB  occurs  during  a  two-day  period.  The  events  assodated  with  the 
APB  are  shown  in  Figure  B-2. 


Dayl  Day  2 


Figure  B-2.  Assessment  Participants  dieting  Activities 


•  Participants  Bri^fmg,  This  briefing  indudes  a  schedule  of  assessment 
events,  including  locations  and  times  of  these  events,  the  designated 
partidpants,  and  an  explanation  of  the  importance  of  the  free  flow  of 
information.  IWo  potential  concerns  may  inhibit  the  free  flow  of 
information: 

-  The  organization  may  be  concerned  that  sensitive  information 
about  its  software  engineering  capabilities  may  become  known  to 
its  competitors  or  customers. 
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-  Assessment  partidpants  may  be  concerned  that  information  may 
be  attributed  to  them  by  project  or  name. 

Accordingly,  the  following  rules,  sometimes  referred  to  as  the 
confidentiality  rules,  are  abided  Ity  the  assessment  team: 

1 .  Only  composite  results  are  given  to  management. 

2.  The  assessment  team  and  assessment  partidpants  agree  to  keep 
confidential  all  information  disclosed  during  the  course  of  an 
assessment. 

3.  Since  SEI  collects  the  assessment  data,  it  will  not  release  or  otherwise 
identify  the  results  of  aity  organization's  assessment 

4.  The  SEI  is  free  to  use  assessment  data  and  condusions  to  be 
derived  for  statistical,  analytical,  or  reporting  purposes,  provided 
that  the  confidentiality  requirement  can  be  honored  and  that  the 
information  can  be  used  without  attribution  to  its  source,  either 
directly  or  by  inference. 

5.  The  SEI  will  not  publish  collective  data  extemalfy  unless  such  data  is 
based  upon  information  from  not  less  than  ten  different  (x^g^nizatitm 

6.  Project-spedfic  data  is  retained  by  the  SEI. 

•  SEI  Questions.  The  assessment  team  explains  some  of  the  key  terms 
used  in  the  questionnaire,  and  then  the  PLs  respond  to  the  questions. 

•  Response  Analysis.  The  responses  are  transcribed  to  a  response  matrix. 
The  assessment  team  analyzes  the  response  matrix. 

•  Develop  Ejqfloratory  Areas.  The  team  develops  exploratory  questions, 
based  on  the  analysis.  The  questions  are  then  ranked  and  a  script 
developed  for  each  project. 

•  Final  Planmngfor  OSP.  The  team  reviews  and  verifies  the  logistics  for 
the  OSP  in  terms  of  the  time  and  place  each  person  or  group  will  meet. 
Requests  are  made  for  any  materials  that  may  be  required  for  the  OSP, 
such  as  overhead  projectors,  whiteboards,  paper,  pencils,  tape,  etc. 


On-Site  Period 


The  OSP,  shown  in  Figure  B-3,  is  the  most  a*itical  activity  of  the  assessment 
and  requires  the  complete  involvement  and  commitment  of  all  team  mem¬ 
bers.  Because  of  the  limited  time  available  during  the  OSP,  it  is  essential 
that  the  time  is  used  effectively.  Each  event  during  this  week  is  discussed 
below. 


B-7 


Appendii  B.  Software  Procea  A«c«meiit  Melhodi 


Dayl 

Dmy2 

Days 

0^4 

Days 

Opening 

Meeting 

Functional 

Alta 

DncusioDS 

Project  Leader 
Feedback 

leamDiy 

RunRndingi 

IVesentatkm 

Final 

Findings 

Review 

Eqplontcey 

Areas 

Develop 

IVelinunaty 

landings 

Develop 

Final 

Findings 

Eieciaive 

Session 

(Optional) 

- 1 - 

1 

1 

IVoject 

Leader 

Discussions 

FL  Dry  Run 
landings 
IVesentation 

Briunstom 
Draft  Beconi- 
mendatioas 

Final 

Assessment 

landings 

Ddirief 

I 


Next  Steps 

HgureB-3.  Oii>Site  Period  Activities 


•  OpemngMeetii^.  This  briefing  includes  a  schedule  of  the  week’s  events, 
including  locations,  times,  and  designated  participants. 

•  Final  Review  of  Exploratory  Areas.  The  assessment  team  verifies  that  the 
scripts  developed  during  the  APB  are  correct  and  properly  ranked. 

•  Project  Leader  Discussiotts.  These  structured  discusskxis  are  held 
individually  with  eadi  designated  FL  and  are  guided  by  the  scripc 
e}q)ioratoiy  questitMis  develq)ed  duriitg  the  APB  period. 

•  Functiorud  Area  Representative  Discusskms.  These  discussions  are 
somewhat  different  from  the  structured  discussions  with  the  PLs.  A 
functional  area  is  typcally  a  group  of  working  professionals  who  come 
from  a  representative  functional  area  of  a  project.  Usually  there  are  four 
functional  area  groups,  with  eight  to  ten  software  professionals  in  each: 

-  Quality  assurance  and  release 

-  Software  integration  and  test 
~  Code  and  unit  test 

-  Requirements  and  design 

•  Develop  PreUminaryFindu^.  The  assessment  team  shifts  its  focus  from 
data  gathering  to  data  interpretation  by  analyzing  the  data  and  devel¬ 
oping  preliminary  findings.  The  role  of  the  findings  is  to  represent  the 
assessment  team’s  view  of  the  most  important  software  process  issues 
currently  facing  the  organization.  The  findings  represent  the  starting 
point  for  formulating  recommendations  on  how  the  organization 
needs  to  improve  with  regard  to  software  process. 
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•  Ait^LeiufcrAerfbaeifcSesmfis.  A  session  is  held  with  ead)  of  the  PLs 
to  review  the  preliminary  findings. 

•  />niefop /bio/ flMintgxArifilt.  The  final  findings  are  a  result  of  all  the 
{Mreviously  collected  data,  the  team  input,  and  the  PL  feedbadc  to  the 
preliminary  findings.  The  structure  of  the  draft  final  findings  is 
different  from  that  of  the  {veliminaiy  findings;  the  assessment  team 
identifies  the  associated  causes  of  eadi  finding  and  resultant 
consequences. 

An  aimotated  outline  of  the  final  findings  presentation  can  be  found 
in  Appendix  C. 

•  Dry  Run  Findings  Presentations.  Before  making  a  presentation  to  senior 
management,  it  is  important  for  the  ATL  to  perform  dry  runs  of  the 
presentation.  The  value  of  this  is  for  the  ATL  to  become  completely 
familiar  with  the  presentation  material  and  also  for  the  assessment 
team  to  receive  feedbadc  from  the  PLs  and  FARs  to  determine  \diether 
the  findings  are  accurate  and  complete. 

•  Final  Findings.  This  allows  the  assessment  team  to  make  any  diai^es, 
based  on  the  feedback  from  the  diy  runs,  and  to  finalize  the  presentation. 

•  Final  Findings  Presentation  and  Executive  Session.ThtALrLpttsentsihe 
final  findings  to  senior  management  and  the  assessment  partidpants. 
After  making  the  findings  presentation  to  management,  an  optional 
executive  session  is  held.  Iliis  session  is  conducted  if  senior  manage¬ 
ment  would  like  to  gain  some  further  insight  into  the  assessment  or 
findings. 

•  Drqft  Recommendations.  The  assessment  team  begins  developing 
recommendations  asscxnated  with  the  assessment  findings  while  the 
week’s  activities  are  still  fresh  in  their  minds. 

•  Assessment  DdtrUf.  This  debrief  captures  lessons  learned  to  improve 
the  assessment  process,  including  the  assessment  team  training,  the 
APB,  and  the  OSP. 

•  Next  Steps.  The  purpose  of  this  activiQr  is  for  the  assessment  team  to 
understand  and  plan  the  next  steps,  which  are: 

-  To  develop  a  findings  and  reconunendations  report  and  briefing 

-  lb  present  a  briefing  to  senior  management  on  the  recommendations 

-  To  begin  planning  process  improvements 

Additional  Sources  of  Information 

Humphrey,  W.S.,  and  W.L.  Sweet  A  Method  for  Assessing  the  Scftvme 

Engineaing  Capability  of  Contractcns.  Tfechnical  Report  CMU/SEI-87-TR-23. 
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Pittsburgh,  Pennsyivania;  Sc^tware  Engineeriiig  Institute,  Carnegie  MeUon 
University,  1987. 

Software  Process  Assessment  Tiam  Member^  Guide.  Versitm  12.  Pittsburgh, 
Penntyivania:  Skrftware  Engineoing  Institute,  Cam^e  MeUon  Unimsity, 
September  1992. 


lU  PROCESS  ADVISOR 


R.S.  Pressman  &  Associates,  Inc.,  has  developed  a  ^tematic  af^oach  to 
software  engineering  process  improvement  that  is  reflected  in  its  product. 
Process  Advisor  This  multimedia  product  guides  an  organization  through 
six  tedmolpgy  transition  (^e  segments: 

•  Process  Assessment.  Before  an  organization  can  worry  about  the  nuts 
and  bolts  of  technology  transition,  it  must  take  a  hard  look  at  current 
software  development  practices.  Process  assessment  refers  to  both 
qualitative  and  quantitative  information  gathering  that  enables  an  or¬ 
ganization  to  determine  the  maturity  with  whidi  it  develops  software, 
lb  do  this,  a  series  of  questions  must  be  asked,  answered,  and  correctly 
interpreted. 

•  Education.  Most  software  managers  and  developers  know  relatively 
little  about  software  engineering,  lb  increase  the  level  of  software  en¬ 
gineering  knowledge,  an  organization  must  develop  an  effective 
education  strategy  that  (1)  is  tied  to  the  results  of  the  process  assess¬ 
ment,  and  (2)  coordinates  training  content  and  timing  with  immediate 
project  needs  so  that  maximum  benefit  can  be  attained. 

•  Sdection.  Selection  defines  specific  goals  and  criteria  for  selection  of 
software  ei^eering  procedures,  methods,  and  computer-aided  soft¬ 
ware  engineering  (CASE)  tools,  and  leads  to  the  development  of  a  ra¬ 
tional  mechanism  for  dioosing,  costing,  justifying,  and  acquiring  these 
important  elements  of  software  engineering  technology. 

•  Justification.  £]q)enditures  for  scrftware  engineerii^  procedures,  methods, 
education,  CASE  toc^  and  associated  siqipcxt  activities  must  be  shown  to 
provide  a  return  on  investment  befixe  raoaey  is  committed.  A  justification 
model  is  used  to  demonstrate  the  bottom-line  benefits  of  process 
improvement 

•  Installation.  In  order  to  install  software  engineering  technologies 
successfully,  a  transition  plan  must  be  devised  and  then  executed.  The 
plan  defines  tasks,  responsibilities,  milestones,  and  deliverables,  and 
specifies  a  schedule  for  getting  the  work  done. 

•  Evabuxtion.  ..ic  managers  make  dianges  to  improve  the  development 
process,  select  and  install  new  tedmology,  and  then  stidt  their  heads  in 
the  sand,  not  spending  nearly  enou^  time  evaluating  whether  the 
technology  is  working.  The  evaluation  step  performs  an  ongoing 
assessment  of  the  CASE/software  engineering  installation  process. 

In  the  sections  that  follow,  the  first  step— process  assessment— is  considered 
in  more  detail. 
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Process  Assessmeot  Approach 

The  term  process  assessment  refers  to  both  qualitative  and  quantitative 
information  gathering.  When  process  assessment  is  properly  conducted, 
it  satisfies  the  following  objectives: 

•  Provides  a  framework  for  an  objective  examinaticm  an  organizatitm’s 
software  development  practices 

•  Indicates  technical  and  management  strengths  and  weaknesses  in  a 
way  that  allows  for  comparison  to  industry  norms 

•  Establishes  an  indication  of  the  relative  software  developanent  maturity 
of  an  organization 

•  Leads  to  a  strategy  for  jn^ocess  improvement  and,  indirectly,  to  the 
improvement  of  software  quality 

In  order  to  accomplish  these  objectives,  the  process  assessment  relies  on 
a  set  of  questions  that  inquire  about  an  organization’s  process  attributes. 
By  interpreting  the  answers  conectly,  an  organization  takes  the  first  step 
toward  improving  its  practices. 


Structure 


Although  there  are  many  different  process  assessment  approaches,  all 
have  the  same  basic  structure: 

•  Assessment  Questions.  The  questions  are  designed  to  enable  an  assessor 
to  gather  enough  information  to  gain  an  understanding  of  the  software 
organization,  the  application  of  technology  within  it,  and  the  relative 
sophistication  of  the  project  management  framework  for  applying  the 
technology.  The  questions  are  of  three  types:  qualitative  questions  re¬ 
quiring  a  narrative  response,  boolean  questions  requiring  a  yes/no 
response,  and  quantitative  questions  requiring  a  munerical  response. 

•  Response  Evaluation.  Responses  to  the  questions  are  evaluated  to 
determine  the  process  maturity  level  by  following  these  steps: 

—  Responses  to  boolean  questions  are  used  to  derive  a  maturity  value. 

-  Responses  to  quantitative  questions  are  compared  to  industiy 
averages,  when  available. 

-  Responses  to  qualitative  questions  are  used  to  provide  additional 
insight  into  the  current  process. 

•  Interpreting  the  Results.  The  maturity  values  computed  from  the  responses 
to  boolean  assessment  questions  can  jM'ovide  a  means  for  developing  a 
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transition  [dan  for  process  improvement  Idealfy,  maturity  values  are 
assigned  to  one  of  a  number  of  process  attributes  (e^^  organizational 
policies,  [M-oject  mana^ment  apfffoacfa,  software  quality  assurance). 
Based  on  the  maturity  value,  an  organization  can  rank  process  attributes 
in  order  of  their  importance  and  impact  on  local  efforts  to  imjx^ove 
process. 

Once  process  attribute  areas  have  been  ranked,  interpretation  b^ins. 
Hained  staff  members  with  tedinology  transition  esqierience  or  eapnt 
outside  consultants  evaluate  the  results  the  assessment  and  develop  an 
organizationally  specific  set  of  findings  and  recommendations.  Findings 
describe  specific  areas  of  strength  or  weakness  and  recommendations 
define  the  actions  that  will  be  required  to  imp-ove  the  software 
development  process. 

Process  Advisor  Assessment  Model 

The  Process  Advisor  assessment  model  has  been  designed  to  enable 
self-directed  assessment  Ity  those  organizations  that  want  to  begin  software 
engineering  tedinology  transition  activities  without  incurring  substantial 
initial  expense. 

Responses  to  the  qualitative  and  quantitative  questions  are  assessed  using 
a  quasi-expert  system  that  is  built  into  the  model.  Each  response  to  the 
questionnaire  is  compared  to  a  set  of  typical  responses.  The  quasi-expert 
system  provides  a  set  of  inferences  that  help  an  organization  to  develop 
findings  and  recommendations  based  on  the  response. 

Boolean  questions  address  eight  process  attributes: 

•  Organizational  policies  that  guide  the  use  of  software  engineering 
practices 

•  Haining  that  supports  the  use  of  procedures,  methods,  and  tools 

•  Framework  (procedural  model)  that  has  been  established  to  define  a 
software  engineering  process 

•  QA  activities  for  software 

•  Project  management  tasks  that  plan,  control,  and  monitor  software 
work 

•  Software  engineering  methods  and  techniques  that  enable  technical 
staff  to  build  high-quality  applications 

•  CASE  tools  that  support  the  methods 

•  Software  metrics  and  measurement  that  provide  insight  into  the  process 
and  its  product 
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Responses  to  the  boolean  questionnaire  portion  of  the  Process  Advisor 
model  generate  process  attribute  ‘'grades”  for  each  of  the  eight  attributes, 
as  shown  in  Thble  B-1. 

TaUe  B-1.  Grade  Interpretation  for  Each  Process  Attribute 


Grade  Range 

Identifier 

Description 

Below  1.65 

E 

Rudimeiitaiy  practice:  Common  in  even  the 
most  undisciplined  organization 

1.65  to  2.25 

D 

Improved  practice:  Representative  of  those 
software  (tevek^)ment  organizations  that  have 
begun  to  improve  their  software  engineering 
approach 

2.26  to  2.75 

C 

Advanced  practice:  A  discq^ine  and  related 
activities  t^t  are  to  be  found  in  the  top  5  to 

10%  of  all  software  developers 

2.76  to  3.25 

B 

Excellent  practice:  The  best  possible  approach 
to  a  particular  software  engineering  activity, 
given  commercially  availaUe  technology 

Above  3.26 

A 

State-of-the-art  practice:  Idealized  practice  that 
is  currently  unattainaUe  in  industry 

These  process  attribute  grades  form  an  organization’s  process  maturity 
“footprint,”  as  shown  in  Figure  B-4,  thus  providing  an  indication  of 
relative  strengths  and  weaknesses  in  the  process  attribute  areas. 

Developing  Findings  and  Recommendations 

Findings  and  recommendations  are  derived  from  the  results  of  the 
assessment.  It  is  sometimes  difGcult  to  interpret  the  assessment  results. 


Organizational 

Policies 


Project 

Management 


Figure  B-4.  Organization  "Footprint” 
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however,  in  a  manner  that  will  lead  to  pragmatic  recommendations  for 
change,  lb  assist  in  this  activity,  this  aj^roach  provides  a  set  of 
inference-based  guidelines  that  are  tied  to  different  maturity  levels  for 
each  of  the  process  attributes  under  assessment.  Once  the  assessment  has 
been  completed,  the  maturity  grade  for  each  process  attribute  is 
determined.  The  grade  range  provides  a  solid  indication  of  both  finding 
and  recommendations. 

As  an  exam{:de  of  inference-based  guidelines,  consider  the  following  findings 
and  recommendations  that  are  reproduced  from  the  Process  Advisor 
Workbook: 

THE  SOFTWARE  DEVELOPMENT  PROCESS 

Questions  in  the  Software  Engineering  Process  section  of  the  process 
assessment  questionnaire  explore  the  emphasis  on  the  software 
engineering  process  as  it  is  defined  for  yoi^^'  organization.  The  questions 
focus  on  standards  as  a  way  to  determine  whether  you  have  codded  your 
approach.  Examine  your  grade  and  place  it  in  the  context  of  the  grade 
ranges  in  Ikble  B-2: 

lkbleB-2.  Grade  Range  Mapping 


Grade  Range 

Identifier 

Below  1.65 

E 

1.65  to  2.25 

D 

226  to  2.75 

C 

2.76  to  325 

B 

Above  3.26 

A 

Here’s  how  to  interpret  the  results: 

E  and  D:  It  is  unlikely  that  you  have  developed  a  written  description  of  your 
process.  In  fact,  it  is  unlikely  that  you  have  defined  a  process  in  any  explicit 
manner. 

Action:  Begin  by  aeating  a  skeletal  framework  for  software 
engineering— that  is,  a  set  of  activities,  deliverables,  milestones  and  QA 
actions  that  can  be  applied  as  software  is  being  developed.  Wite  a  description 
of  the  ftamework  and  solidt  comments  and  recommendations  from 
managers  and  technical  staff.  Over  time,  rework  the  ftamewoi  k,  adding  more 
detail,  until  it  evolves  into  a  standard. 

C  and  B:  Your  organization  has  codified  many  of  the  activities  assodated  with 
software  development  It  is  likely  that  the  same  approach  is  applied  aaoss 
different  projects  and  that  project  planning,  control  and  QA  are  easier  to 
adiieve  as  a  result  But  a  word  of  caution  is  necessary  here:  just  because 
standards  CTst  does  not  mean  that  the  proce.ss  is  effective  or  properly 
characterized. 
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Action:  Each  of  the  standards  should  be  reviewed  to  determine  if:  (1)  they 
reflect  modern  software  engineering  practice;  (2)  there  are  aspects  that 
can  be  streamlined;  (3)  there  are  aspects  that  just  don’t  work  very  well. 
Time  should  be  spent  polling  development  staff  to  get  their  feelings  on  the 
standards  and  to  determine  whether  the  standards  are  being  used  as  widely 
as  these  grade  ranges  imply.  Specific  technical  areas  without  standards  can 
be  determined  by  reviewing  responses  to  individual  questions.  It  may  be 
worthwhile  to  develop  a  framework  approach  for  a  specific  technical  area 
(e.g.,  testing)  in  a  manner  similar  to  that  described  in  the  action  paragraph 
for  E  and  D  ranges. 

ADomoNAL  Sources  of  Information 

Pressman,  Roger  S.  A  Manager's  Guide  to  Software  Engineering.  New  York, 
New  York:  McGraw-Hill,  1993. 

Process  Advisor  Tool: 

R.S.  Pressman  &  Associates,  Inc. 

620  East  Slope  Drive 
Orange,  CT  06477 
(203)  795-5044 
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B3  ISO  9000 


This  desaiption  provides  an  overview  of  the  ISO  9000  standards,  their 
application  to  so^are,  and  an  overview  of  a  framework  against  to 
conduct  an  audit  of  your  processes  against  ISO  9000.  For  more  detail  on 
ISO  9000  and  how  to  apply  it  to  your  own  processes,  refer  to  Section , 
Additional  Sources  of  Information. 


OVERVIEIV  OF  ISO  9000 


ISO  9000  is  a  family  of  standards  that  covers  the  requirements  for  quality 
management  systems  (QMS)  for  manufactured  products  and  services. 
Quality  is  defined  as  the  totality  of  features  or  characteristics  of  a  product 
or  service  that  bear  on  its  ability  to  satisfy  stated  or  implied  needs. 

The  purpose  of  ISO  9000  is  to: 

•  Clarify  the  distinctions  and  interrelationships  among  the  principal 
quality  concepts 

•  Provide  guidelines  for  the  selection  and  use  of  a  series  of  international 
standards  on  quality  systems  that  can  be  used  for  internal  quality  man¬ 
agement  purposes  (ISO  9004)  and  for  external  QA  purposes  (ISO 
9001, 9002, 9003) 

ISO  9000  follows  the  principle  that  quality  system  standards  provide  a 
framework  for  management  control.  The  standards  lay  down  specific  re¬ 
quirements,  but  they  do  not  tell  an  organization  how  to  structure  itself, 
how  to  perform  activities,  how  to  document  the  system,  or  even  what  pro¬ 
cedures  to  write.  In  addition,  quality  system  standards  such  as  ISO  ^01 
are  industry  independent.  Because  of  its  wide  application  and  general  ap¬ 
proach,  however,  the  standard  requires  interpretation  for  specific  indus¬ 
tries.  For  example,  ISO  9000-3  is  the  interpretation  of  the  ISO  standard  for 
software  development. 

ISO  9000  comprises  a  series  of  quality  system  standards  models  and 
associated  guidelines.  Each  is  introduced  briefly  below: 

•  ISO  9001, 9002,  and  9003  are  the  models  for  quality  system  standards. 
ISO  9002  and  ISO  9003  are  subsets  of  ISO  9001. 

-  ISO  9001  is  the  QA  model  for  organizations  that  control  their 
quality  in  the  whole  manufacturing  process,  from 
design/development  and  production  to  installation  and  servicing. 

—  ISO  9002  is  the  QA  model  for  organizations  that  control  their 
quality  only  in  production  and  installation. 
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-  ISO  9003  is  the  QA  model  for  organizations  that  control  their 
quality  only  in  final  inspection  and  test. 

•  ISO  9000-2  and  ISO  9000-3  provide  the  guidelines  for  how  to  af^y 
ISO  9001, 9002,  and  9003. 

-  ISO  9000-2  is  the  guide  to  the  application  of  ISO  9001, 9002,  and 
9003. 

-  ISO  9000-3  provides  ^he  guidelines  for  the  application  of  ISO  9001 
to  the  development,  supply,  and  maintenance  of  software. 

Figure  B-S  shows  the  relationships  among  the  ISO  9000  standards  related 
to  software. 

ISO  9001  was  designed  to  establish  and  assess  QMS  for  a  variety  of 
industries.  The  structure  and  terminology  of  ISO  9001,  however,  is  more 
applicable  to  hardware  manufacturing  than  to  software  development,  lb 
address  this  concern,  ISO  developed  ISO  9000-3  as  the  standard  guide  for 
applying  ISO  9001  to  software  development,  supply,  and  maintenance. 

lb  audit  against  ISO  9001,  the  HcklT  scheme  was  set  up  by  the  United 
Kingdom  (UK)  software  industry  under  the  stewardship  of  the  British 
Computer  Society.  HcklT  is  an  accredited  quality  management  certifica¬ 
tion  ^stem  tailored  to  meet  the  needs  of  the  software  and  information 
technology  industries.  The  main  objectives  of  HcklT  are  to  raise  aware¬ 
ness  of  what  is  quality  and  how  it  may  be  managed,  and  to  provide  a  QMS 
certification  scheme  that  is  recognized  by  purchasers  and  users,  and  whidi 
commands  the  respect  of  the  information  technology  professional. 

TickIT  focuses  mainly  on  software  development  because  of  its  power  and 
flexibility,  its  key  role  in  information  systems,  and  its  propensity  to  be  the 
source  of  many  problems.  HcklT  guidance  relates  to  the  construction  and 
formal  assessment  of  software  quality  systems  for  registration  to  the  re¬ 
quirements  of  ISO  9001  through  the  application  of  ISO  9000-3  guidance. 

The  result  of  a  successful  ISO  9001  audit  is  a  certificate  of  compliance. 

Performing  an  ISO  9001  Audit  for  Software 

This  desCTiption  provides  a  summary  of  the  TickIT  certification  process 
for  assessing  an  organization’s  quality  systems  against  the  requirements  of 
ISO  9001  through  the  application  of  ISO  9000-3. 

A  quality  audit  is  defined  as  a  systematic  and  independent  examination  to 
determine  whether  quality  activities  and  related  results  comply  with 
planned  arrangements,  and  whether  these  arrangements  are  implemented 
effectively  and  are  suitable  to  achieve  objectives.  A  quality  audit  is  not  an 
alternative  to  an  inspection  operation;  it  is  a  fact-finding  process  used  to 
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determine  the  suitability  of  and  conformance  to  the  organization’s  quality 
systems  to  the  documented  requirements. 

The  following  lists  three  types  of  quality  audits. 

1 .  Internal  or  First-Party  Audit.  The  audit  is  performed  by  the  organization 
itself  to  determine  the  degree  of  compliance  against  the  standard. 

2.  External  or  Second-Party  Audit.  The  audit  is  performed  by  a  customer  or 
third  party  to  determine  the  degree  of  comi^iance  of  the  suf^liers’  quali¬ 
ty  tystem  against  the  standard  selected  by  the  customer  or  third-party. 
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3.  Extrinsic  or  Hurd-Party  Audit.  The  audit  is  performed  an  external, 
impartial  body  or  regulatory  authority  to  determine  the  degree  of  com¬ 
pliance  against  the  standard.  The  external,  impartial  body  must  be  ac¬ 
credited  by  a  recognized  national  accreditation  authority  if  the 
organization  is  to  receive  a  certificate  of  compliance. 

This  method  uses  the  following  role  definitions:  The  auditor  is  the  person 
or  group  possessing  the  qualifications  to  p)erform  quality  audits;  the  audi- 
tee  is  the  organization  being  audited;  the  auditor  managing  the  audit  is  the 
lead  auditor. 

There  are  three  phases  in  performing  an  ISO  9001  audit  for  software 
development:  pre-audit,  audit,  and  post-audit.  These  phases  are  discussed 
in  the  following  sections. 


Pre-Audit 


The  pre-audit  process  includes  the  following  steps.  Each  step  provides 

guidance  for  both  the  auditee  and  the  auditor,  as  appropriate. 

•  Scope.  The  auditee  must  define  the  scope  of  its  organization  to  be 
audited.  When  drafting  the  scope,  the  auditee  needs  to  keep  the 
following  in  mind:  Software  development  work  must  form  part  of  the 
activities  of  the  scoped  area;  the  definition  of  the  scope  must  broadly 
reflect  the  business  functions,  services,  and  typical  products  supplied 
to  its  customers;  the  scope  must  cover  not  just  the  software  in  isolation, 
but  also  the  surrounding  systems  areas;  and  the  scope  should  reflect 
any  particular  market  niches  of  the  organization.  The  objective  of  the 
auditee  is  for  the  audit  to  cover  all  aspects  of  the  quality  system  within 
that  scope.  In  the  scope,  the  auditee  also  identifies  which  standards  the 
organizations  wishes  to  be  compliant  against. 

The  statement  of  scope  is  used  by  the  lead  auditor  to  plan  the  audit, 
which  includes  selecting  projects  and  functions  to  demonstrate  the  au¬ 
dited  organization’s  capability,  estimating  the  duration  of  the  audit, 
and  selecting  auditors  with  the  appropriate  background. 

•  Auditor  Team.  The  auditee  typically  requests  quotations  from  two  or 
three  certified  auditors,  based  on  the  scope  of  the  audit.  The  auditee 
then  selects  the  desired  auditor  and  issues  a  contract. 

The  members  of  the  audit  team  should  have  technical  expertise  in  the 
methods,  techniques,  and  tools  used  in  the  auditee’s  organization; 
leadership  qualities,  experience  in  team  management,  and  the  ability 
to  deal  with  difficult  interpersonal  relationships;  and  be  independent 
of  the  auditee’s  organization  (i.e.,  not  have  any  current  work  assign¬ 
ments  with  them).  Auditors  who  perform,  a  third-party  audit  must  be 


B-20 


certified  a  national  acaeditation  authcmty.  Both  the  size  of  the 
team  and  the  time  needed  for  the  audit  depend  on  the  scope  of  the  au¬ 
dit,  the  number  of  locations  to  be  audited,  and  the  organization's  oom- 
plezity.  An  audit  of  a  small  organization  can  be  conducted  by  one 
person;  a  major  audit  of  a  large  organization  should  be  conducted  by 
several  auditors. 

Pre-Audit  Iitformation.  The  auditee  provides  information  about  its 
company  to  the  auditors  so  they  can  adequately  prepare  for  the  audit. 
The  needed  information  is  usually  included  in  the  auditee’s  quali^ 
manual,  a  requirement  of  the  quality  systems  standard.  Other  infor¬ 
mation  the  auditee  provides  includes  policies  and  procedures,  market¬ 
ing  information,  organizational  structures,  and  any  other  information 
that  can  offer  insight  into  the  business  and  activities  of  the  auditee’s 
organization. 

The  lead  auditor  requests  in  detail  the  information  needed.  After 
receiving  the  information,  the  lead  auditor  evaluates  the  content  of  the 
documentation  against  the  quality  system  standard  and  proposed 
scope. 

Prdiminary  Auditor  Visit.  The  auditors  may  visit  the  auditee  organization 
prior  to  the  audit  and  review  the  auditee’s  quality  management  ^tems. 
This  may  be  necessary  if  the  information  provided  in  the  previous  step 
did  not  provide  enough  information  for  the  auditor  to  adequately  plan  for 
the  audit.  The  preliminary  visit  can  offer  the  following  benefits:  The  audi¬ 
tor  can  make  sure  the  auditee  completely  understands  the  audit  process; 
the  auditor  can  notify  the  auditee  of  any  significant  omissions  or  devi¬ 
ations  from  the  ISO  9001  requirements  that  need  to  be  addressed  prior 
to  the  audit;  and  the  auditor  has  the  opportunify  to  review  as  much  of  the 
documented  qualify  system  as  possible  before  the  audit 

Audit  Program.  It  is  impossible  for  an  auditor  to  investigate  all  of  the 
qualify  activities  within  an  organization  during  one  audit  period, 
■nierefore,  the  auditor  makes  sure  the  team  looks  at  a  representative 
sample  of  activities  or  evidence.  By  defining  ahead  of  time  the  areas 
to  be  audited,  and  knowing  how  much  time  is  allocated  for  the  audit 
the  auditors  can  plan  and  prepare  how  the  audit  will  be  conducted.  The 
audit  program  includes; 

-  Location  to  be  audited 

-  Purpose  and  scope  of  the  audit 

-  Dates,  including  starting  time  for  the  opening  meeting  and  starting 
time  for  the  closing  meeting 


-  Timed  program  of  visits 


-  Names  of  the  audit  team  members 

The  auditor  forwards  the  audit  program  to  the  auditee  before  the  audit 
so  that  the  auditee  can  make  the  necessary  arrangements.  Negoti¬ 
ations  often  take  place  between  the  auditor  and  the  auditee  on  the  final 
program. 

The  auditors  also  indicate  the  extent  of  coverage  of  the  ISO  9001 
standard  that  will  be  achieved  by  the  audit  program,  detailing  the 
coverage  by  area  within  the  auditee’s  organization  if  possible. 

•  Audit  Team  BrufU^.  If  there  are  more  than  two  auditors,  the  lead 
auditor  holds  an  audit  team  meeting  to  review  the  scope  and  objectives 
of  the  audit,  plan  preparation  of  checklists  (see  next  step),  and  share 
any  information. 

•  ChecUists.  The  auditor  develops  checklists  to  be  used  to  audit  each 
area  of  the  auditee’s  organization.  These  checklists  should  be  devel¬ 
oped  by  the  entire  audit  team.  They  provide  a  well-balanced,  well¬ 
paced  structure  to  the  audit,  and  are  especially  beneficial  if  auditors 
are  reassigned  from  area  to  another. 

In  preparing  the  checklists,  the  auditors  define  which  quality  system 
standards  will  be  audited  in  each  work  area.  Guidance  for  preparing 
checklists  include: 

-  The  auditors  should  be  fully  knowledgeable  of  the  objectives  and 
scope  of  the  audit  and  the  ISO  9001  standard. 

-  A  minimum  of  one  checklist  per  work  area  being  audited  should 
be  used. 

-  The  number  of  items  on  the  checklist  depends  on  the  complexity 
of  the  audit  and  the  amount  of  time  available  for  the  audit  of  that 
work  area. 

-  The  amount  of  detail  needed  in  a  checklist  is  at  the  discretion  of 
the  auditor  performing  that  part  of  the  audit. 

-  The  auditor  should  not  be  afraid  to  stray  away  from  the  checklist 
if  information  arises  that  will  provide  insight  into  that  work  area’s 
quality  system  practices.  The  auditor  must  ensure,  however,  that 
enou^  time  remains  to  cover  all  checklist  items. 

From  the  initial  decision  to  audit  the  organization  throughout  the  audit,  the 
auditee  must  ensure  that  the  organization  is  aware  of  the  forthcoming  audit, 
review  all  projects  and  groups  prior  to  the  audit,  prepare  a  list  of  all  projects 
currently  active,  ensuring  that  all  different  types  of  projects  identified  in  the 


scope  are  deaiiy  kkDtiikd;  and  assure  that  die  administrate  iieals 
aufitor  (e^  wM’k  ^Moe)  are  met 


Anfit 


The  audit  process  indudes  the  following  steps: 

•  Start-Up  The  start-up  meeting  is  diaired  by  the  lead  auditor. 

The  auditee  organization’s  management  must  attend  to  show  the  orga¬ 
nization’s  commitment  to  the  audit  In  this  meeting,  the  objectives  and 
scope  of  the  audit  are  explained  to  the  auditee  organization’s 
management,  all  arrangements  are  confirmed,  responsibilities  for  the 
audit  are  confirmed  (see  next  step),  the  general  rules  of  the  audit  are 
established,  the  audit  process  is  reviewed,  aiul  auditee  questions  are 
answered. 

•  AuditBespoiaibiMes.  Auditing  groups  are  formed  to  conduct  the  audit 
There  may  be  one  or  more  groups,  depending  on  the  number  of  audi¬ 
tors.  Each  auditing  group  should  consist  of  the  auditor(s),  a  guide  from 
the  auditee  organization,  a  manager  from  the  area  being  visited,  and 
other  observers  witnessing  the  audit  Each  role  is  described  briefly 
below; 

-  The  auditor  is  responsible  for  auditing  the  assigned  area  of  the 
auditee’s  organization. 

-  The  guide  escorts  the  auditors  from  one  department  to  another 
and  introduces  them  to  the  involved  staff  of  the  area  being  audited. 

—  The  manager  answers  any  questions  and  provides  any  information 
in  support  of  the  audit. 

-  Observers  learn  from,  but  do  not  take  part  in,  the  audit. 

•  Paform  Audit,  The  auditor  performs  an  in-depth  appraisal  of  the 
auditee’s  procedures  and  the  overall  management  structure  for 
compliance  with  ISO  9001,  using  applicable  guidance  material  from 
ISO  9000-3.  The  auditor  looks  at  a  representative  sample  of  projects 
to  perform  the  audit. 

The  auditors  compare  the  auditee’s  organization  quality  manual  and 
standards  to  ISO  9001,  using  the  checklists  to  discover  any  nonconfor¬ 
mities.  The  auditee  representative  is  asked  to  confirm  any  nonconfor¬ 
mity.  The  auditor  is  responsible  for  identifying  and  justifying  any 
nonconformities  that  are  found. 

Before  the  closing  meeting,  the  lead  auditor  meets  with  the  auditors 
and  collects  all  of  the  nonconformities.  The  audit  team  decides  which 


B-23 


AiycadiiB.  Softw*  Proce«  Awewiiieiu  MeUwdt 


nonconformities  to  combine,  i^re,  or  declare  as  a  nonoonfonnity, 
and  the  lead  auditor  decides  which  of  the  nonoonformities  to  declare 
as  a  major  or  minor  nonconformity.  A  major  nonconformity  occurs 
when  there  is  an  absence  and/or  breakdown  of  a  quality  system  ele¬ 
ment.  A  minor  nonconformity  occurs  when  there  is  an  occasional 
instance  of  failure  in  a  quality  system  element 

The  lead  auditor  then  prepares  a  summary  statement,  the  auditors 
prepare  a  nonconformity  statement,  and,  optionally,  the  full  report  is 
prepared. 

•  Closing  Meeting.  The  dosing  meeting  is  the  climax  of  the  entire  audit 
At  the  closing  meeting,  the  lead  auditor  restates  the  audit  process  that 
was  followed,  stressing  the  fact  that  only  a  sample  of  the  au^tee's  orga¬ 
nization  was  visited,  and  then  presents  the  summary  report  and  the 
noncompliance  statement  The  auditee  representative  signs  acknowl¬ 
edgment  of  the  nonconformities.  The  closing  meeting  is  chaired  by  the 
lead  auditor. 

If  the  audit  was  done  by  a  third  party,  then  recommendations  for 
certification  are  not  made  at  the  dosing  meeting.  For  second-party 
auditors,  recommendations  are  announced  at  the  dosing  meeting  onty  if 
this  is  agreed  to  by  both  parties.  Hrst-party  audits  usually  present  the 
recommendations  for  certification  at  the  dosing  meeting. 

The  organization  uses  the  closing  meeting  to  start  the  next  cycle  of 
improvement,  based  on  the  findings  of  the  audit. 


Post-Audit 


If  a  certificate  of  compliance  was  awarded,  then  a  third-party  certification 
body  will  make  regular  surveillance  visits,  typically  twice  a  year,  to  ensure 
that  the  company  is  still  following  the  agreed  practices. 

In  order  to  retain  its  certification  and  maintain  quality,  an  organization 
must  continually  improve  its  documented  quality  system. 

AoDinoNAL  Sources  of  Informahon 

International  Organization  for  Standardization,  ISO  9000-3,  1st  ed., 
1991-06-01,  Geneva,  Switzerland,  1991. 

Hckrr  Project  Office,  Guide  to  Software  Quality  Management  System 
Construction  and  Certification,  EN  29001/BS  5750  Part  1  (1987),  Issue  2.0, 
(London,  England:  ncklT  Project  Office,  1992). 
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Excel  Partnership,  Incx,  and  Georgia  Institute  of  Ifecfanology  Center  for 
International  Standards  and  Quality,  /SO  9000  Software  Ijead  Auditor 
(course  taught  in  Atlanta,  Georgia,  10-14  May  1993). 

Registrar  Acaeditadtm  Board,  Guide  to  Software  Qaal^  System  Construction 
and  Registraticm,  Issue  0.1,  Milwaukee,  IMsomsin:  R^trar  Accreditation 
Board,  1993. 
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This  page  intentionalfy  Ufi  blank. 


APPENDIX  C.  ASSESSMENT  FINDINGS 
PRESENTATION  OUTLINE 


Append  Objective 

Ruwie  an  outlme  fco’ 
stmctunng  a  findings 
pnsentation 


This  appendix  provides  an  annotated  outline  for  presenting  the  final 
findings  from  an  assessment,  along  vdth  an  example  presentation. 


C.1  PRESENTATION  CONTENT 

This  section  provides  an  outline  of  the  presentation,  with  comments  on  the 
general  content  of  each  potential  slide.  Ibxt  in  triangular  brackets  denotes 
instructions  for  placement  of  text  or  graphics. 

TmjE 

The  text  or  graphics  may  be  unique  to  your  organization  or  reference 
specific  parts  of  this  guidebook. 

Set  the  context  of  this  briefing  to  focus  on  the  findings  derived  from  the 
assessment. 

Agenda 


List  the  topics  that  are  to  be  discussed  during  this  presentation. 


Assessment  Timetable 

List  the  key  activities  conducted  during  the  assessment  and  when  they 
occurred. 

Scope  of  the  Assessment 

Present  the  following  attributes  of  the  assessment: 

•  Type  of  assessment  performed 

•  List  of  projects  representing  the  organization 

•  Functional  areas  covered 
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•  Number  of  assessment  team  members 

•  Ibtal  number  of  participants  from  the  organization 


Assessment  Process  Flow 

Describe  the  basic  flow  of  the  assessment 

Organizations  Composite  Status 

If  a  numerical  rating  was  established,  present  it  here.  You  may  also  want 
to  give  an  impression  of  the  findings,  such  as  ‘‘numerous  poUdes,  stan¬ 
dards,  and  guidelines  exist,  but  are  not  consistently  apfdied.”  Alternative¬ 
ly,  depending  upon  your  organization’s  culture,  you  may  want  to  present 
this  information  at  the  end. 


Strengths 


Findings 


List  the  major  organizational  strengths  that  exist. 


List  all  the  major  findings  categories  that  are  to  be  presented. 
Name  of  First  Findings  Category 


Flnding(s) 

•  List  a  finding  in  this  category. 

-  Include  a  list  of  any  observations  that  support  this  finding. 

•  List  any  other  findings  in  this  category. 

-  Include  a  list  of  any  observations  that  support  these  findings. 

Consequences 

•  List  an  undesirable  coa^equence  of  these  findings. 

•  List  any  other  undesirable  consequences  of  these  findings. 

Name  of  Findings  Category  N 

Repeat  the  information  for  each  findings  category. 

Next  Steps 

Present  a  list  of  activities  that  the  organization  should  perform  to  improve 
the  organization’s  practices. 
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Composite  Status 


•  ABC  Ccxporate  DivisioQ  is  at  the  Initial  level  of 
software  process  maturity. 


Strengths 


•  People  with  “can  do"  attitude 

*  Commitment  to  custcxner  support 

•  Diverse  workforce 

*  Flexibility  and  adaptability 


Findings 

*  Project  Planning  and  Estimating 

*  <list  additional  Endings  categories  here  > 


C  Anenment  Findiagt  Presentation  Outline 


APPENDIX  D.  ASSESSMENT  FINDINGS  AND 
RECOMMENDATIONS  REPORT  TEMPLATE 


This  appendix  provides  you  with  an  annotated  template  for  your  findings 
and  recommendations  report. 

As  with  any  well-written  report,  this  report  should  have  a  title  page  and 
table  of  contents,  though  this  template  does  not  show  them. 

D.1  EXECUTIVE  SUMMARY 

The  executive  summary  serves  as  a  synopsis  of  the  report.  A  reader  should 
be  able  to  get  a  general  idea  of  the  findings  from  an  assessment  and  of  the 
recommendations  made  by  the  assessment  team  and  PG  by  reading  this 
summary.  Everything  discussed  in  the  executive  summary  should  be 
covered  in  the  document  in  more  detail.  The  executive  summary  should  be 
the  last  part  of  the  report  you  write.  If  you  do  a  good  job  on  the  other 
sections,  you  can  develop  a  first  draft  of  the  executive  summary  by 
rephrasing  paragraphs  from  the  rest  of  the  report. 


/^peudix  Objective 

Pronde  a  template 
forajindmgpand 
recommendations 
report 


Introduction 


Discuss  briefly  the  events  that  led  to  an  assessment  and  the  assessment 
itself. 

Include  an  overview  of  the  contents  of  this  report. 

Name  of  First  Findings  Category 

Discuss  the  major  finding  that  was  derived  from  the  assessment  and  the 
recommendations  for  improvement  that  were  proposed.  This  section 
should  be  kept  to  one  concise  paragraph.  The  titles  of  these  sections  should 
correspond  exactly  to  the  findings  categories  presented  in  the  findings 
presentation. 

Name  of  Findings  Category  N 

Repeat  this  section  for  each  major  findings  category. 


Next  Steps 

Discuss  briefly  the  next  steps  that  you  feel  should  be  taken  to  begin 
implementing  the  recommendations. 
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m  ORGANIZATION  PROCESS  STATUS 

Discuss  the  maturity  of  your  organization’s  processes.  If  a  numerical  rating 
was  established,  present  it  here.  Give  a  hi|^-level  impression  of  the  find¬ 
ings,  such  as  “numerous  policies,  standards,  and  guidelines  exist,  but  are 
not  consistently  applied.” 

If  any  projects  exhibit  good  practices,  mention  those  practices.  Do  not 
identify  any  projects  specifically. 

Include  a  brief  discussion  on  the  organization’s  strengths. 

D3  KEY  FINDINGS  AND  RECOMMENDATIONS 

In  this  section  you  identify  the  key  findings  and  assodated  recommendations. 
Provide  a  list  of  the  findings  that  you  discuss. 

Name  of  First  Findings  Category 


Introduction 

Provide  an  overview  of  the  findings  category. 

Finding(s) 

Present  the  finding(s)  in  this  category,  exactly  as  presented  in  the  findings 
presentation: 

•  State  the  finding  in  general  terms. 

-  State  specific  observations  that  support  this  finding. 

•  State  any  other  findings  in  general  terms. 

-  State  specific  observations  that  support  these  findings. 

Discussion 

Discuss  the  finding(s)  in  greater  detail. 

Consequences 

Discuss  the  consequences  the  organization  is  experiencing  due  to  the 
observations  supporting  the  findings  category. 

Recommendation  (s) 

Present  the  recommendations  to  improve  the  practices  in  this  findings 
category  that  the  organization  should  implement: 
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•  State  the  first  recommendation 

•  State  the  n*^  recommendation 

Recommendations  stated  in  bullet  form  are  used  directly  in  the  findings 
and  recommendations  presentation. 


Discussion 


Discuss  in  greater  detail  the  recommendations  made  and  the  positive 
consequences  the  organization  should  experience. 

Name  of  Findings  Category  N 

Repeat  Section  for  each  major  findings  category. 


D.4  NEXT  STEPS 

In  this  section  you  introduce  the  five  to  seven  activities  that  the 
organization  should  perform  to  improve  the  organization’s  practices, 
lypically,  these  steps  are  steps  from  the  process  improvement  process 
(i.e.,  Analyze  Risks  and  Select  Strategy,  Plan  Improvements,  Implement 
Improvements,  Review  and  Update,  and  Understand  Context).  After 
completing  these  steps,  the  organization  should  be  prepared  to  reassess 
the  organization’s  practices. 

Name  of  First  Step 

Describe  briefly  the  activities  to  be  performed  within  this  step  and  why  this 
step  is  important. 

Name  of  N™  Step 


Describe  briefly  the  activities  to  be  performed  within  this  step  and  why  this 
step  is  important. 

D.5  APPENDIX:  CONDUCTING  THE  ASSESSMENT 

This  appendix  provides  the  reader  with  an  overview  of  the  assessment 
activities  performed,  the  lessons  learned,  and  the  projects  and  functional 
areas  assessed. 


D.6  GLOSSARY 


D-3 


Provide  a  glossary  of  key  words  found  in  the  report. 
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This  page  intentionalfy  left  blank. 
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RECOMMENDATIONS  PRESENTATION  OUTLINE 


This  appendix  provides  you  with  an  annotated  outline  for  [vesenting  the 
recommendations  from  an  assessment  to  all  those  involved  in  both  the  as¬ 
sessment  and  the  process  improvement  program  in  general.  This  informa¬ 
tion  is  taken  directly  from  the  findings  and  recommendations  report, 
outlined  in  i^pendix  D.  An  example  presentation  is  also  induded. 


E.1  PRESENTATION  CONTENT 

11)  is  section  provides  an  outline  of  the  presentation,  with  conunents  on  the 
general  content  of  each  potential  slide. 


Append  Objective 

Provide  m  outline  for  a 
fitrdingmnd 
recommendations 
presentation 


TnuE 

Set  the  context  of  tliis  briefing  to  focus  on  the  recommendations  derived 
from  the  assessment. 

AGEND4 


List  the  topics  that  are  to  be  discussed  during  this  presentation. 


Assessment  Timetabl£ 

List  the  key  activities  conducted  during  the  assessment  and  when  they 
occurred. 

Scope  of  the  Assessment 

Present  the  following  atfributes  of  the  assessment: 

•  Type  of  assessment  performed 

•  List  of  projects  representing  the  organization 

•  Functional  areas  covered 
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•  Number  of  assessment  team  members 

•  Ibtal  number  of  participants  from  the  organization 

Assessment  Process  Flow 

Describe  the  basic  flow  of  the  assessment 


ORGANIZATION’S  COMPOSITE  STATUS 

If  a  numerical  rating  was  established,  present  it  here.  You  may  also  want 
to  give  a  high-level  impression  of  the  findings,  such  as  "numerous  policies, 
standards,  and  guidelines  exist  but  are  not  consistently  applied.** 

Findings  and  Recommendations 

List  all  the  major  findings  categories  that  are  to  be  presented. 

Name  of  First  Findings  Category 

The  findings  and  consequences  should  come  directly  firom  the  findings 
presentation. 


Finding(S) 


•  List  a  finding  in  this  category. 

-  Include  a  list  of  any  observations  that  support  this  finding. 

•  List  any  other  findings  in  this  category. 

-  Include  a  list  of  any  observations  that  support  these  findings. 

Consequences 

•  List  a  consequence  of  these  findings. 

•  List  any  other  consequences  of  these  findings. 


Name  of  First  Findings  Category  (Continued) 

The  recommendations  should  come  directly  from  the  findings  and 
recommendations  report 
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RecoaMMadatioa(s) 

•  List  a  recommendation  to  improve  the  practices  in  this  category. 

-  List  any  supporting  information. 

•  List  any  other  recommendations  to  improve  the  practices  in  this 
category. 

-  list  any  supporting  information. 

Name  of  Findings  Category  N 

Repeat  the  two  previous  slides/charts  for  each  findings  category. 

Next  Steps 

Present  a  list  of  activities  that  the  organization  should  perform  to  improve 
the  organization’s  practices. 
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E  J  EXAMPLE  FINDINGS  AND  RECOMMENDATIONS  PRESENTATION 

An  example  based  on  the  above  outline  is  shown. 


ABCCoqxxrate  DhrisioQ 

Software  I^ooess  Assessment 
landings  and  Reoammendatioas 


January  29. 1994 


r 

A 

Agenda 

• 

Assessment  Background 

• 

Composite  Status 

• 

Strengths 

• 

Findings  and  Recommendations 

• 

Next  Steps 

V. 

j 

Assessment  Timetable 

• 

Assessment  learn  ’Bairring 

28-30  Oct 

• 

Assessment  Partidpants  Briefing 

23-24  Nov 

• 

On-site  Assessment 

7-11  Dec 

• 

Recommendations  IVesentation 

29  Jan 

• 

Action  Plan  Review 

TBD 

• 

Reassessment 

TBD 
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Scope  of  the  Assessmeot 


Assessment  foUcwed  die  SEI-prescribed  process 
S  rqnesenUtive  projects: 

<list  representative  projects  here> 

35  representatives  from  the  fdlcwing  areas: 

<list  functional  areas> 

11  assessment  team  members 


Assessment  Process  Flow 


<insert  Figare  B-3  here> 


SEI  Process  Maturity  Levels 


<insert  Kgure  B-1  hero 


Appendix  R  AMCwment  Findingi  and  ReownmendatioM  Presentation  Outlae 
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Finding  Category  N 


Recommendations 

•  <list  lecoauaendatioa  bere> 

-  <listsubrecoDimendationshei<e> 

•  <list  a<klitional  reooomModatioos  here> 


' - 

c 

Next  Steps 

*  RiskAnalysis 

*  Action  Plan 

*  Action  Plan  Briefing 

*  Actk»  Plan  Imi^ementatioa 

*  Reassessment 


APPENDIX  F.  RISK  MANAGEMENT  PLAN 

TEMPLATE 


AppenJUx  Objective 

Protide  a  template  fw  a 
risk  maru^ement  plan 


The  purpose  of  this  plan  is  to  capture  the  risks,  their  probability  and 
impact,  and  the  plan  to  manage  them,  as  identified  during  the  risk 
assessment.  This  document  captures  which  techniques  and  methods  the 
manager  is  using  to  identify,  analyze,  and  mitigate  the  risks.  It  also 
provides  a  place  to  collect  and  organize  all  information  concerning  the 
project’s  risks  that  is  necessary  to  present  to  senior  management. 

Once  the  risk  management  plan  is  developed,  the  plan  will  continue  to  be 
updated  with  information  concerning  whether  the  identified  risk  has  oc¬ 
curred,  the  effect  of  the  risk  mitigation  strategy  planned  for  the  risk,  and 
any  other  risk-related  information  that  would  be  useful  in  future  risk 
analysis. 

Tbilor  this  plan  to  capture  the  essential  characteristics  of  the  project’s 
environment.  Focus  on  understanding  what  you  absolutely  must  do,  what 
you  should  not  do,  and  what  you  may  do  if  appropriate. 

The  risk  management  plan  will  be  reviewed  and  updated,  as  required,  during 
the  course  of  the  project.  Section  F3,  Analysis  of  Spiral  Risk  at  Cyde  N,  will 
be  repeated  ’n  its  entirety  for  eadi  tycle. 


El  PURPOSE  AND  SCOPE 

In  this  section,  document  the  purpose  and  scope  of  the  risk  management 
plan  in  terms  of  the  objectives.  Outline  who  is  responsible  for  which  por¬ 
tions  of  the  risk  management  plan,  and  who  are  to  be  the  performers  of  the 
risk  mitigation  strategies.  Document  any  assumptions  or  constraints  that 
the  risk  management  plan  is  working  under. 

E2  SELECTED  RISK  MANAGEMENT  METHOD 

This  section  documents  and  describes  the  selected  risk  management 
techniques  to  be  used.  Identify  which  technique  has  been  selected  to 
measure  the  probability  of  a  risk,  measure  the  impact  of  a  risk,  and 
measure  the  combined  probability  and  impact.  Also  include  how  risks  are 
to  be  measured  over  time. 

Once  a  specific  risk  management  technique  is  selected,  it  should  remain 
in  place  for  the  duration  of  the  project,  so  that  the  risk  values  can  be 
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recalculated  after  spedfic  risk  initiation  strate^es  have  been  applied. 
Using  the  same  risk  analyst  and  same  method  will  aid  with  traddng  risks 
over  time. 

E3  ANALYSIS  OF  SPIRAL  RISK  AT  CYCLE  N 

This  section  is  cycle  specific  and  may  be  repeated  in  its  entirety  for  eadi 
subsequent  cyde. 

Overview 

The  purpose  of  this  section  is  to  capture  an  overview  of  the  cyde  and  v^t 
is  trying  to  be  accomplished  in  that  tyde.  Document  the  tyde  objectives, 
assumptions,  and  constraints.  List  any  items  being  referenced. 

Risk  Identification 

Document  the  specific  risks  within  the  following  categories: 

•  Orgamzpdonal  Ksks.  These  risks  involve  the  aspects  of  the  different 
approaches  and  capabilities  that  an  organization  can  bring  to  a  system 
development  effort. 

•  Process  Kdcs.  These  risks  involve  the  aspects  of  system  engineering 
approaches  used  to  develop  products. 

•  Product  Risks.  These  risks  are  inherent  within  the  software-intensive 
system  itself. 

In  this  section  you  document  the  risks  and  map  each  risk  to  goals, 
objectives,  alternatives,  and  constraints.  If  appropriate,  document  known 
triggers  for  a  risk  and  the  potential  damage  for  each  risk  item.  Also  indude 
the  amount  of  risk  that  is  acceptable  for  each  individual  risk  and  the 
acceptable  level  of  overall  spiral  risk.  Document  references  for  the  somces 
of  risk. 

Risk  Analysis 


In  this  section,  you  document  a  list  of  high-priority  risk  items.  Fbr  each  of 
these  risks  document  the  following  information: 

•  Risk  desCTiption 

•  Cause 
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Consequence  of  occurrence 
Probability  of  occunence 


FrequeiM^  of  occurrence 
Risk  factor 
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•  Time 

•  Coupling/oompounding  risk 

Also  include  any  additional  information  necessary  to  su]^rt  the  analysis. 


RlSKEVALUAnON 

For  each  high-prioriQr  risk,  document  the  identified  risk  mitigation 
strategy.  The  following  information  should  be  included: 

•  Identification,  ranking,  and  analysis  of  alternative  strategies  for 
mitigating  the  high-priority  risks 

•  Identification  of  any  new  risks  associated  with  the  identified 
alternative  strategies 

RlSKMlTIGAnON 

Document  each  risk  mitigation  strategy  that  has  been  identified.  Indude 
a  desCTiption  of  each  mitigation  strategy,  the  spedfic  risk(s)  that  you  will 
mitigate,  a  WBS  that  lists  the  individual  tasks  that  you  need  to  accomplish, 
constraints,  guidance,  an  estimate  of  how  long  it  will  take  to  complete  each 
task,  when  the  task  is  to  begin,  an  estimate  of  the  resources  required,  plans 
for  monitoring  the  risk  mitigation  activities,  products  to  be  produced,  and 
the  aiteria  for  success  (i.e.,  when  you  will  consider  the  risk[s]  to  be 
averted). 

Results 


At  the  completion  of  a  mitigation  strategy,  document  the  impact  that  the 
technique  had  on  eadi  risk  that  it  affected.  Document  cost  and  sdiedule 
metrics  for  the  mitigation  strategy,  and  note  how  the  risk  mitigation  strate¬ 
gy  was  executed.  Identify  and  document  the  new  probability,  consequence, 
and  frequency  of  occurrence  of  the  affected  riste. 


Hus  page  intentionaify  kfi  blank. 


APPENDIX  G.  ACTION  PLAN  TEMPLATE 


Aj^e$i£x  (Xfjectiv* 

Provide  a  template  for 
anacdonplan 


This  appendix  provides  you  with  a  temjdate  for  an  action  plan.  Refer  to 
Section  6.1,  Define/Update  Action  Plan,  for  a  complete  discussion  on  the 
action  plan,  including  logical  structure,  contents,  and  planning  tasks.  (The 
action  plan  template  in  this  appendix  does  not  correspond  directly  to  the 
illustration  presented  in  Hgure  6-2.) 

The  action  plan  may  be  structured  according  to  your  needs.  The  plan 
presented  here  is  hierarchical  in  nature,  but  the  numbering  scheme  and 
page  numbers  must  be  changed  to  reflect  a  stand-alone  document.  You 
may  wish  to  include  a  title  page  and  table  of  contents. 


G.1  EXECUTIVE  SUMMARY 

The  executive  summary  serves  as  a  synopsis  of  the  entire  action  plan.  A 
reader  should  be  able  to  get  a  gener^  idea  of  the  motivation,  approach, 
schedule,  staffing,  and  risks  associated  with  the  process  improvement  ef¬ 
fort  by  reading  this  sununary.  Everything  discussed  in  the  executive  sum¬ 
mary  should  be  covered  in  the  document  in  more  detail.  The  executive 
summary  should  be  the  last  part  of  the  plan  you  write.  If  you  do  a  good  job 
on  the  other  sections,  you  can  develop  a  first  draft  of  the  executive 
summary  by  rephrasing  paragraphs  firom  the  rest  of  the  action  plan. 


Events  Leading  to  Action  Plan 

Establish  a  historical  context  for  the  action  plan.  Conduct  the  following: 

•  Discuss  the  events  that  led  to  the  decision  to  conduct  an  assessment. 

•  Review  briefly  the  steps  of  the  assessment  that  led  to  the  findings  and 
recommendations  report. 

•  Discuss  the  steps  taken  to  write  the  action  plan. 

Purpose  of  Action  Plan 

The  purpose  of  an  action  plan  is  to  implement  the  improvements 
identified  in  the  findings  and  recommendations  report.  This  section 
discusses,  in  general  terms,  how  the  action  plan  supports  the  findings  and 
recommendations  report  and  relevant  corporate  objectives. 
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Major  Recommendations  and  Intiial  Actions 

Introduce  the  major  recommendations  from  the  findings  and 
recommendations  report,  and  discuss  the  first  improvement  actions  that 
will  be  taken.  The  purpose  of  this  section  is  to  inform  the  reader  of  what 
comes  next,  specifically: 

•  Actions  to  be  implemented  first 

•  Actions  that  will  produce  the  most-needed  improvement 


Criteria  for  Success 


In  general  terms,  discuss  how  you  will  evaluate  the  success  of 
implementation  of  this  action  plan.  This  section  should  be  a  summary  of 
the  milestones  and  evaluation  section  of  the  appendix  on  new  technologies 
and  procedures,  found  in  Section  G.7. 


Summary  of  Schedule 


Discuss  the  major  milestones  of  the  sdiedule.  This  section  should  be  a 
summary  of  the  information  discussed  in  Section .  Be  sure  to  discuss  sever¬ 
al  near-term  milestones.  This  section  should  convince  the  reader  that 
there  will  be  a  steady  stream  of  benefits,  rather  than  a  long  period  of  work 
with  no  visible  payoff. 


G.2  INTRODUCTION 


The  purpose  of  the  first  two  sections  of  the  introduction  is  to  convince  the 
reader  that  the  action  plan  is  worth  implementing.  The  remaining  five  sec¬ 
tions  introduce  and  summarize  concerns  that  are  addressed  in  detail  in  lat¬ 
er  sections  of  the  plan.  Each  of  the  remaining  sections  should  indicate 
where  the  reader  can  find  more  detailed  information. 


Initiative  to  Improve 


Briefly  discuss  the  reason(s)  your  organization  needs  to  improve  its 
software  process. 


Benefits 


Discuss  the  benefits  you  expect  to  result  fi'om  your  process  improvement 
effort.  Indicate  how  your  organization’s  corporate  objectives  are  to  be 
served  by  implementing  the  actions  in  this  plan. 
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AcnoHS 

Summarize  the  key  process  areas  that  are  addressed  by  the  action  [dan  and 
the  most  important  actions  in  each  area. 

AcnoN  Plan  Management 

Discuss  your  overall  strategy  for  funding,  staffing,  and  sdieduling  the 
process  improvement  effort.  You  can  refer  the  reader  to  the  section  on 
Action  Plan  Management,  Section  G.4. 

Risk  Analysis 

Summarize  your  approach  to  risk  analysis,  the  major  risks  you  identified, 
and  the  way  you  plan  to  address  them.  Briefly  state  the  constraints  you 
must  live  with  and  how  these  constraints  impose  risks. 

Process  Action  Teams 

Name  and  summarize  the  purpose  of  each  PAT 

New  Technologies  and  Procedures 

Briefly  discuss  the  major  new  technologies  and  procedures  that  are  to  be 
adopted  under  this  plan.  It  is  not  necessary  to  mention  every  addition,  but 
you  should  say  something  about  the  new  technologies  and  procedures  that 
are: 

•  Most  beneficial 

•  Most  prone  to  risk 

•  Most  challenging  to  implement 

G3  ACTIONS 

This  section  defines  your  responses  to  the  assessment  team’s  findings  and 
recommendations.  This  section  should  convince  the  reader  that  each  rec¬ 
ommendation  has  been  considered  durii^  the  action  planning  process,  that 
the  response  to  eadi  recommendation  is  reasonaUe,  and  that  die  new  tecfando- 
gies  and  procedures  to  be  introduced  will  not  adversely  impact  ongoing 
projects. 

Recommendations  and  Responses 

In  this  section,  you  organize  recommendations  by  process  area  and  discuss 
the  response  to  each  recommendation.  Mention  every  recommendation  in 
the  findings  and  recommendations  report.  If  you  dedded  not  to  imple¬ 
ment  a  recommendation,  justify  the  decision  in  the  assodated  response. 
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Name  of  First  Process  Area 

Include  one  section  for  each  process  area  that  is  mentioned  in  the  findings 

and  recommendations  report  or  that  is  addressed  by  this  action  plan. 

If  a  recommendation  applies  to  several  process  areas,  include  it  in  the  most 

appropriate  area.  Do  not  discuss  a  recommendation  more  than  once.  Use 

a  format  similar  to  the  following: 

•  Rxommendation.  Summarize  briefly  a  recommendation  or  a  group  of 
recommendations  that  have  a  common  response. 

•  Response.  Describe  the  response  to  the  recommendation  in  the 
previous  paragraph.  In  most  cases,  the  response  will  involve 
implementing  one  or  more  of  the  new  technologies  or  procedures 
described  in  Appendix  B  in  Section  G.7.  Note  that  several  actions  can 
be  associated  with  a  particular  new  technology  or  procedure.  Fbr 
example,  introduction  of  a  new  software  design  tool  involves 
purchasing  the  tool,  installing  it  on  one  or  more  platforms,  training 
engineers  in  its  use,  establishing  a  mechanism  for  resolving  problems, 
and  introducing  the  tool  to  existing  projects.  Describe  each  action 
separately  since  you  may  allocate  actions  for  a  single  new  technology 
or  procedure  to  more  than  one  PAT.  Show  how  each  action  supports 
corporate  initiatives. 

If  you  choose  not  to  follow  a  recommendation,  explain  why. 

•  Recommendation.  Repeat  this  paragraph  for  each  recommendation  in 
the  process  area. 

•  Response.  Repeat  the  response  for  each  recommendation. 

Name  of  Second  Process  Area 

Repeat  this  section  for  each  process  area  addressed  by  this  action  plan. 


TRANsmoN  TO  Projects 


Process  improvement  involves  acquiring  new  technology,  adding  new 
procedures  to  your  software  development  process,  and  modifying 
procedures  that  are  already  in  place.  Often,  new  technologies  and 
procedures  must  be  tailored  for  existing  projects.  In  this  section,  you 
discuss  the  impact  you  expect  new  technology  and  procedures  to  have  on 
existing  projects  and  sununarize  guidelines  for  tailoring  them  for  ongoing 
projects.  Include  detailed  tailoring  instructions  with  the  technology  and 
procedure  descriptions  in  Appendix  B,  found  in  Section  G.7. 
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Expected  Impact  on  Existing  Projects 

Explain  how  new  technologies  and  procedures  are  expected  to  impact 
existing  projects. 

Guidelines  for  Integrating  Wtth  Existing  Projects 

Summarize  guidelines  for  tailoring  procedures  and  adapting  new 
technology  for  existing  projects.  The  adaptation  should  involve  additional 
actions  beyond  those  described  in  Section .  List  the  additional  actions  in 
this  section. 

G.4  ACTION  PLAN  MANAGEMENT 

The  purpose  of  this  section  is  to  identify  the  PAI^  that  cany  out  the  process 
improvement  actions,  the  funding  allocated  to  each  group,  and  the 
schedule. 


Approach 


Introduce  and  justify  your  approach  to  managing  process  improvement. 
Work  Breakdown  Structure 

The  WBS  is  a  hierarchical  decomposition  of  a  process  improvement  task 
into  increasingly  detailed  subtasks.  This  section  should  include  a  diagram 
of  the  tasks  and  subtasks  and  a  brief  (one  line)  description  of  each.  Link 
each  task  and  subtask  back  to  the  actions  discussed  in  Section . 

Organizing  for  Process  Improvement 

In  this  section,  you  introduce  the  groups  that  are  to  implement  the  action 
plan.  Name  and  describe  briefly  each  PAT.  Provide  detailed  desaiptions 
in  Appendix  A,  found  in  Section  G.6. 

Include  an  organization  chart  that  shows  reporting  responsibilities  and 
other  interactions  among  groups.  The  PG  should  oversee  the  entire  effort. 

Responsibiltty  Matrix  (Resource  Allocation) 

In  this  seaion,  you  allocate  the  actions  described  in  Section  to  the  PAIk 
introduced  in  Section .  Specify  who  is  to  implement  each  action  and  who 
is  to  evaluate  its  implementation.  In  many  cases,  you  will  allocate  different 
actions  for  the  same  improvement  to  several  teams. 

Consider  using  a  matrbc  to  map  actions  to  teams. 


Budget 


Describe  the  source  and  amount  of  funding  for  each  of  the  working  groups 
introduced  in  Section . 
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Schedule 


The  schedule  should  show  the  planned  starting  and  ending  times  for  each 
action  described  in  Sections  and ,  as  well  as  dependencies  between  actions. 
If  possible,  it  should  also  show  when  each  action  will  impact  each  project. 
Consider  using  a  Program  Evaluation  and  Review  Technique  or  Gantt 
chart  to  represent  the  schedule.  Remember  that  the  process  improvement 
effort  should  produce  a  steady  stream  of  visible  results;  you  must  have 
short-term  and  long-term  milestones  in  order  to  ensure  continued  buy-in. 


Crtteru  for  Success 

In  this  section,  you  discuss  how  you  will  measure  success  both  while  the 
action  plan  is  being  implemented  and  after  all  actions  are  in  place. 

For  each  process  area,  track  success  at  least  to  the  level  of  goals.  You  may 
track  success  to  the  level  of  individual  practices,  or  to  an  even  flner  level 
of  detail,  if  you  choose. 

G.5  RISK  ANALYSIS 

In  general,  the  objective  of  risk  analysis  is  to  develop  an  understanding  of 
possible  impediments  to  process  improvement  and  to  decide  how  you  will 
deal  with  those  impediments  if  they  arise.  In  this  section,  refer  to  the  risk 
management  plan.  You  may  choose  to  provide  an  overview  of  key  risks  and 
mitigation  strategies  here. 

G.6  APPENDIX  A:  PROCESS  GROUP  AND  PROCESS  ACTION  TEAM  CHARTERS 

In  this  section,  provide  a  detailed  description  of  each  group  involved  in 
implementing  this  action  plan.  Be  sure  to  indude  any  existing  groups,  such  as 
the  PG.  Some  groups,  sudi  as  temporary  investigative  committees,  may  be  too 
informal  to  include  in  this  appendbt. 


Name  of  First  Group 

For  each  group,  describe  its  mission  (purpose),  life  span  (length  of 
existence),  responsibilities,  positions  for  individuals  within  the  group,  the 
individuals  above  and  below  the  group  in  the  chain  of  command,  and  any 
other  individuals  or  groups  with  which  the  group  will  interact.  Also  list  the 
members  of  the  group. 
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Mission  Statement 


Briefly  describe  the  purpose  of  the  group. 


Life  Span 


Certain  groups,  such  as  those  devoted  to  adapting  new  technology  and 
procedures  to  existing  projects,  may  have  a  limited  life  span.  Indicate  in 
this  section  how  long  each  group  is  expected  to  operate.  If  possible,  tie 
temporary  groups  to  a  pair  of  milestones:  one  for  the  point  at  which  the 
group  begins  to  function,  and  the  other  for  the  point  at  which  the  group 
disbands. 

Detailed  Group  RESPONSieiunES 

Use  a  list  to  describe,  in  detail,  the  responsibilities  of  the  group. 

PosmoNS  WmnN  Group 

Name  and  desaibe  the  responsibilities  of  each  tmique  position  within  the 
group.  Examples  of  positions  include  group  leader,  technologist,  and 
technical  writer. 


Members  of  Group 


List  the  name  and  position  of  each  member  of  the  group.  For  each,  indicate 
how  they  can  be  contacted,  what  percentage  of  their  time  they  will  allocate 
to  the  group,  and  how  long  they  will  be  members. 

Supervising  Individuals  or  Groups 

List  the  individuals  or  groups  above  this  group  in  the  chain  of  command. 


Subordinate  Groups 


List  the  groups  below  this  group  in  the  chain  of  command. 

Interactions  With  Other  Groups 

List  groups  (other  than  superior  or  subordinate  groups)  with  which  this 
group  is  to  interact  on  a  regular  basis.  Describe  the  nature  of  the 
interaction. 


Name  of  Second  Group 


Repeat  this  section  for  each  group  involved  in  implementing  this  action 
plan. 
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a?  APPENDIX  B:  NEW  TECHNOLOGIES  AND  PROCEDURES 

In  this  section,  desaibe  each  new  tedmology  or  procedure,  justify  its 
adoption,  discuss  what  other  technologies  and  procedures  must  in  place 
for  it  to  work,  list  the  skills  required  to  use  it,  and  discuss  how  it  can  be 
tailored  for  use  on  specific  projects. 

The  information  requested  can  be  obtained  performing  technology 
transfer  activities  discussed  in  Using  New  Technology  A  Technology 
Thmsfer  Guidebook  (Software  Productivity  Consortium  1993e), 
specifically  by  executing  Cycles  1  and  2  of  the  technology  transfer  process. 

Name  of  First  New  Technology  or  Procedure 

Describe  the  new  technology  or  procedure  and  indude  a  list  of  reference 
material  and  sources  of  expertise. 


Reason  for  Adoption 


Explain  why  your  organization  is  adopting  the  new  technology  or 
procedure.  He  the  technology  or  procedure  to  the  actions  described  in 
Section . 

Enabling  Technologies  or  Procedures 

Describe  any  technologies  or  procedures  that  must  be  in  place  in  order  for 
this  technology  or  procedure  to  work. 

Skills  and  Training  Required 

Describe  skills  and/or  training  needed  by  users  of  the  technology  or 
procedure. 


Tailoring  Approach 

The  tailoring  approach  for  a  spedfic  technology  or  procedure  consists  of 
general  guidelines  (i.e.,  what  can  be  changed  and  what  must  be  left  alone) 
and  detailed  plans  for  tailoring  the  tedinology  or  procedme  to  spedfic 
projects.  Obviously,  plans  for  tailoring  to  spedfic  projects  should  not 
contradict  the  general  guidelines. 

General  Guidelines 


Describe,  in  general  terms,  how  this  technology  or  procedure  can  be 
tailored  for  use  on  existing  and  new  projects.  In  general,  new  tedmologies 
and  procedures  should  be  applicable  to  new  projects  without  tailoring. 
Ikiloring  may  be  necessary  for  existing  projects  and  for  future  projects, 
however,  when  mandated  by  the  customer.  Your  description  should 
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indicate  \i^at  aspects  of  the  technology  or  procedure  might  change  and 
what  aspects  must  be  the  same  for  any  application.  For  aspects  that  might 
change,  include  a  list  of  alternatives. 

Tailoring  for  Specific  Projects 

Indicate  how  you  will  adapt  the  technology  or  procedure  to  eadi  existing 
project.  If  you  know  of  new  projects  that  will  require  tailoring,  discuss  them 
in  this  section  as  well. 

Milestones  and  Evaluation 

Discuss  how  your  organization  will  know  that  the  technology  or  procedure 
has  been  successfully  adopted. 

Name  of  Second  New  Technology  or  Procedure 

Repeat  Section  for  each  new  technology  or  procedure. 


APPENDIX  H.  MEASURING  PROCESS 
IMPROVEMENT 

This  appendix  addresses  what  to  measure,  v^en  to  measure,  and  how  to 
measure  to  determine  and  verify  process  improvement  This  appendix  de¬ 
scribes  the  relationship  between  measurement  practices  and  process  ma¬ 
turity,  the  Goal-Question-Metric  (GQM)  method,  and  suggested  process, 
product  and  management  measurements. 

The  GQM  method  uses  the  following  definitions  for  measurement  and 
metric: 

•  A  measurement  is  a  number  assigned  to  a  directly  observable  aspect 
of  a  process  or  product. 

•  A  metric  is  a  function  of  one  or  more  measurements.  A  metric  may  be 
directly  observable  or  may  be  derived  through  a  calculation  involving 
one  or  more  metrics  and  measurements. 

Refer  to  the  Software  Measurement  Guidebook  (Software  Productivify 
Consortium  1992b)  for  more  information  on  establishing  a  measurement 
program. 

H.1  MEASUREMENTAND  PROCESS  MATURITY 

As  a  software  development  organization  matures,  it  experiences  an 
increasing  level  of  software  process  measurement  activity.  This  section 
discusses  the  organization's  visibility  into  the  software  process  that  exists 
at  various  levels  of  process  maturity. 

Software  Measurement  at  Lowot  Maturity  Levels 

A  software  organization  operating  at  a  low  maturity  level  measures  little 
of  its  software  process.  There  is  no  reliable  way  either  to  assess  the  status 
of  the  product  under  development  or  to  assess  the  effectiveness  of  the 
development  process.  A  process  in  this  state  of  maturity  can  be 
represented  by  the  open  loop  control  system  in  Figure  H-1.  An  open  loop 
control  system  is  characterized  by  an  input  to  establish  the  process  goals 
and  product  requirements,  the  process,  and  an  output  product  that  may  or 
may  not  meet  its  requirements.  The  noise  represents  variabilify  in  the 
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requirements  and  estimates  that  are  the  bases  of  the  process  goals. 
Establishment  of  the  process  goals  depends  on  the  skill  and  eqxrience  oi 
the  project  management.  Any  corrective  action,  required  due  to 
noncompliance  of  the  product  to  its  requirements,  depends  on  the  skill  of 
management  and  technical  staff,  rather  than  actual  information  about  the 
process  and  product.  The  lack  of  measurement  data  precludes  the  use  of 
actual  experience  to  adjust  the  process  for  performance  variances  from  the 
goals. 


IVoduct 

Requirements 

and 

IVooess  Goals 


Figure  H-1.  Software  Development  at  Early  Maturity  Levels 


Software  Measurement  at  Intermediate  Maturiiy  Levels 

A  software  organization  operating  at  an  intermediate  maturity  level 
measures  some  of  its  software  process,  though  is  not  likely  to  derive  full 
benefit  from  the  data  it  obtains.  Therefore,  an  organization  at  this  level 
needs  to  implement  a  well-planned  measurement  program  that  governs 
the  collection  and  use  of  the  measurements.  The  program  would  include 
development  of  software  standards  to  deflne  the  metrics,  and  procedures 
to  collect  and  analyze  them.  Only  then  could  meaningful  benefit  I  '■ 
expected  from  the  measurement  activity.  A  process  in  this  state  of  maturity 
may  be  represented  by  the  open  loop  control  system  in  Figure  H-2.  The 
measurement  activiQr  has  been  initiated,  but  it  has  not  yet  developed  to  the 
point  of  applying  the  measurement  data  to  improve  the  process.  The 
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Figure  H-2.  Software  Development  at  Intermediate  Maturity  Levels 
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ai^lication  of  the  measurement  data  to  adjust  the  (x-ocess  would  ‘'dose  the 
loop." 

Software  Measurement  at  Advanced  Maturdy  Levels 

An  organization  operating  at  an  advanced  maturity  level  has  a  strftware 
development  [n^ocess  that  can  be  represented  by  the  dosed  kx^  feedbadt 
control  system  model  shown  in  figure  H-3.  The  model  is  diaracterized  by 
inputs  for  product  requirements  and  size,  cost,  schedule,  and  quality  goals. 
The  process  functions  that  achieve  these  process  goals  are  measured  at  the 
outputs  of  the  various  process  activities  and  the  process  output  The  jno- 
cess  output  measurements  tend  to  undershoot  or  overshot  its  goals, 
creating  a  variance  in  its  attempt  to  adiieve  its  set  point  The  amount  and 
type  of  variance  is  used  to  determine  the  corrective  action  necessary  for 
the  process  to  meet  its  goals.  Process  improvement  is  adiieved  v^en  the 
variances  become  smaller. 
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Figure  H-3.  Quantitative  Software  Management  Process  at  Advanced  Maturity  Levels 

H,2  GOAL-QUESTION-METRIC  PARADIGM 

Metrics  selection  should  be  based  on  the  goals  of  your  project  and 
organization.  You  can  use  the  GQM  method  (Basili  and  Weiss  1984)  to 
assist  you  in  selecting  spedfic  metrics  to  meet  your  needs.  The  GQM 
method  works  as  follows: 

1.  State  a  single  goal  of  current  importance  to  the  proj  ct. 

2.  Dedde  what  question(s)  you  would  ask  to  determine  if  the  goal  has 
been  met  (or  if  the  go^  is  being  met). 

3.  Select  the  iretric  you  need  to  answer  the  question(s)  of  Step  2. 
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An  examine  of  GQM  as  aj^ed  to  process  improvement  follows: 

1 .  My  goal  is  to  inaease  defect  removal  before  fvactice. 

2.  Questions  may  indude:  *‘How  many  defects  have  been  identified?" 
"How  do  we  go  about  removing  defects?"  "How  long  does  it  take  us 
to  resolve  defects?”  "When  do  we  find  defects?” 

3.  Metrics  that  would  help  answer  these  questions  indude  number  of 
defects  by  life-cycle  phase,  length  of  time  to  fix  defects,  and  effort  to 
fix  defects. 

You  can  use  the  GQM  method  to  help  you  define  measurements  and 
metrics  to  measure  your  organization’s  process  improvements. 

H3  PROCESS  IMPROVEMENT  MEASUREMENT 

This  section  provides  suggestions  for  what  to  measure  and  when  to 
measure  to  quantify  and  verify  improvements  to  your  software 
development  process.  These  measurements  are  categoriz^  into  process, 
product,  and  management  measurements.  Within  each  category,  the 
metrics  are  divided  according  to  whether  th^  support  an  organization  at 
a  low,  intermediate,  or  advanced  level  of  maturify.  The  latter  maturity 
levels  build  on  the  measurements  established  earlier;  therefore, 
measurements  for  more  advanced  maturify  levels  should  be  gathered  by 
the  organization  in  addition  to  the  measurements  listed  for  earlier 
maturify  levels.  Most  of  the  measurements  listed  support  improvements 
in  more  than  one  category. 

Each  category  indicates  when  you  should  collect  the  measurement  data. 
The  data  is  usually  collected  in  the  Manage  and  Monitor  activity  (see  Sec¬ 
tion  7)  in  each  cycle  of  the  process  improvement  process.  The  data  you  are 
able  to  collect  is  dependent  on  the  status  of  eadi  of  the  projects  using  the 
improved  process;  that  is,  you  can  collect  only  the  data  that  is  available 
from  projects  that  are  finished  using,  or  in  the  process  of  using,  some  or 
all  of  the  improved  process. 

When  you  collect  process  improvement  measurement  data,  keep  the 
following  pyjints  in  mind: 

•  It  is  important  that  you  maintain  a  database  of  your  measurements  so 
that  you  show  the  extent  of  the  improvements  made  to  the  process. 
Ideally,  you  can  measure  the  process  before  any  improvements  are 
made  and  use  that  as  a  baseline  against  whi^  to  measure  your 
improvements. 

•  You  will  collect  the  measurement  data  listed  below  from  a  variety  of 
sources  within  your  organization,  including  accounting  reports  for  cost 
and  effort  expended;  project  management  reports  for  schedule. 
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Staffing,  and  plan-related  information;  and  configuration 
management  reports  and  product  status  reports  for  {M-oduct  change 
information. 

•  The  measurements  listed  in  this  section  do  not  refH'esent  a 
comprehensive  list  of  all  measurements  you  need  to  collect.  You  may 
take  only  a  subset  of  these  lists  and  then  supfdement  that  list  with 
measurements  that  are  not  induded  here.  The  final  list  is  up  to  you  and 
your  organization. 


Process  Measurements 


Process  measurements  |n-ovide  insight  into  the  effectiveness  and  effidenqr 
of  a  process. 

•  Low  Maturity.  Organizations  at  a  low  level  of  maturity  must  first  focus 
on  establishing  effective  management  activities.  For  this  reason,  the 
following  process  measurements  provide  insight  into  the  effort 
expended  on  basic  management  tas^. 

The  following  process  measurements  should  be  collected  and 
evaluated  at  major  milestones  (including  the  end)  of  the  projects  using 
the  improved  process. 

-  Cost  and  effort  expended  on  requirements  management  activities 

-  Cost  and  effort  expended  on  project  planning  activities 

-  Cost,  effort,  and  other  resources  expended  on  pofixmingtraddi^  and 
oversi^t  activities  (e.g.,  mcxiitoring  managonait  metrks) 

-  Number  of  changes  made  to  the  software  developHnent  {dan, 
induding  size,  cost,  critical  computer  resources  estimates,  and 
schedule  changes 

-  Cost,  ^K»t,  and  other  resources  oqiaided  chi  poftMming  subcontract 
management  activities 

-  Cost,  effort,  and  other  resources  eaqrended  on  perfcnming  software 
QA  activities 

-  Cost,  effort,  and  other  resources  exporded  cm  pofinmiiig  scrftware 
configuration  manag^ent  activities 

-  Number  of  configuration  item  change  requests  premessed  per  unit 
of  time 
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•  Intrnnediate  and  Advanced  Maturity.  At  intermediate  and  advamed 
levels,  organizations  have  a  well-defined  software  process  covering 
both  management  and  engineering  activities,  and  they  conduct 
supporting  activities,  sudi  as  training,  peer  reviews,  and  intergroup 
coordination,  to  ensure  the  effectiveness  of  their  {vocess  and  the 
quality  of  the  product. 

In  addition  to  the  measures  listed  in  each  activity,  the  following 
process  measurement  data  can  be  collected  during  eadi  <tyde  of  the 
process  improvement  process: 

-  Cost  and  effort  expended  on  process  improvement  activities 

-  Number  of  management  and  staff  using  the  improved  process 

-  Percentage  of  process  users  using  the  improved  process  as 
intended 

-  Percentage  of  process  users  experiencing  the  oipected  benefits 
from  the  improvements 

-  Number  of  management  and  staff  satisfied  with  the  improved 
process 

-  Percentage  of  improvements  that  have  been  incorporated  into  the 
organization’s  ^eming  mechanisms  (e.g.,  polides  and  procedures) 

-  Cost,  effixt,  and  other  resources  eaq^ended  on  oiganizalicmal  activities 
fix  process  assesanent,  development,  and  improvraient 

-  Results  and  recommendations  of  each  process  assessment 

-  Cost  and  effort  expended  on  process  definition  activities 

-  Cost,  effort,  and  other  resources  expended  on  providing  training 
opportunities  to  staff 

-  Results  of  training  evaluations  and  reviews 

-  Number  of  training  attendees 

-  Number  of  training  waivers  granted 

The  following  process  measurements  should  be  collected  and 
evaluated  at  major  milestones  (including  the  end)  of  the  projects  using 
the  improved  process: 
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-  Frequency,  causes,  and  nu^tude  of  replanning  efforts 

-  For  each  identified  software  risk,  the  realized  adverse  impaa 
compared  to  the  estimated  loss 

-  Number  and  magnitude  ofunantidpated  major  adverse  impacts  to 
the  software  project 

-  Average  length  of  time  for  problem  reports  to  be  resolved  (from 
initial  opening) 

-  Cost  and  effort  to  analyze,  implement,  and  test  proposed  changes 

-  Cost,  effort,  and  other  resources  oq^ended  by  the  strftware 
engineering  group  in  support  of  other  software-related  groups 

-  Cost,  effort,  and  other  resources  expended  by  other  software-related 
groups  in  support  of  the  software  engineering  groups 

-  Number  of  peer  reviews  performed 

-  Cost,  effort,  and  other  resources  expended  on  peer  reviews 

-  Number  of  work  products  reviewed 


Product  Measurements 


A  key  element  of  measurit^  process  improvement  is  measuring  the  results 
of  the  process:  the  software  products.  Relevant  product  measurements 
should  be  collected  and  evaluated  at  major  milestones  (induding  the  end) 
of  the  projects  using  the  improved  process.  The  product  measurements 
that  are  relevant  depend  on  the  stage  of  the  project;  for  example,  if  the 
project  has  just  entered  the  design  phase,  you  can  collect  data  on  the 
number  of  requirements  developed. 

•  Law  Maturity.  The  basic  product  measures  that  a  low-maturity 
organization  should  collect  are  based  on  product  requirements  and 
source  code;  requirements  is  the  most  visible  input  to  the  software 
process,  and  code  is  the  most  visible  output. 

-  Number  of  requirements 

-  Number  of  requirement  dianges,  induding  dianges  that  are 
{H’oposed,  open,  aj^oved,  and  incorporated  into  the  baseline 

-  Number  of  requirement  changes  from  the  customer,  end  user,  and 
software  engineering  group 

-  Critical  computer  resources,  such  as  computer  memory  capadty, 
computer  processor  use,  and  communications  channel  capadty 
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-  Number  of  changes  to  configuration  items  that  are  requested, 
approved,  and  incorporated  into  the  baseline 

-  Number  of  problem  reports  for  configuration  items  that  are 
generated,  approved,  and  resolved 

•  Intermediate  and  Advanced  Maturity.  Intermediate  and  advanced 
maturity  organizations  have  insight  into  inputs  and  outputs  associated 
with  ea^  phase  of  the  software  life  cycle.  This  level  of  maturity  allows 
these  organizations  to  measure  the  intermediate  inputs  and  outputs. 
In  addition  to  the  measures  for  the  organization  at  a  low  level  of  matu¬ 
rity,  the  following  are  suggested  product  measurements: 

-  Size  of  requirements  in  number  of  requirements  statements,  number 
of  (function)  boxes  in  ^tem  diagrams,  number  of  (hardware)  boxes 
in  a  computer  network  diagram,  and  number  of  major  subjects  or 
headings  in  a  system  description  document 

-  Size  of  design  in  munber  of  design  statements,  munber  of  program 
design  statements,  and  number  of  structured  narrative  statements 

-  Size  of  code  in  number  of  source  statements  (i.e.,  thousand  source 
lines  of  code,  or  KSLCX!!)  by  language,  new,  added,  modified,  and 
reused;  comments;  number  of  object  code  instructions;  number  of 
words  in  memory;  number  of  screens;  number  of  operators  and 
operands;  and  number  of  tokens 

-  Number  of  tests  and  number  of  test  procedure  steps 

-  Number  of  computer  software  configuration  items  (CSCIs); 
number  of  computer  software  components  (CSCs);  number  of 
computer  software  units  (CSUs);  number  of  hardware  boxes; 
number  of  inputs  and  outputs;  and  number  of  function  points 

-  Size  of  documentation  in  number  of  pages  by  document  t)T>e 

-  Percentage  of  requirements  trac  'd  to  design,  code,  and  test  cases 

-  Percentage  of  test  coverage  achieved 

-  Number  of  defects  found  during  peer  reviews  in  requirements, 
design,  code,  and  test 

-  Number  of  defects  found  in  testing 

-  Number  of  changes  incorporated  into  the  software  baseline  by 
category  (e.g.,  interface,  security,  performance,  system 
configuration,  and  usability) 
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Management  Measurements 

Management  measurements,  sometimes  referred  to  as  project 
measurements,  provide  insight  into  the  j^ogress  of  a  project,  lliey 
measure  the  management  attributes  of  the  software  development  |n‘ocess. 

Management  measurements  should  be  collected  and  evaluated  at  major 
milestones  (including  the  end)  of  the  jR’ojects  using  the  improved  process. 
Management  measurements  that  are  relevant  depend  on  the  stage  of  the 
project;  for  example,  if  the  project  has  just  entered  the  design  phase,  then 
you  can  collect  data  on  the  estimated-to-actual  time  and  effort  spent  in 
requirements  activities. 

•  Low  Maturity.  At  a  low  level  of  maturity,  organizations  focus  on  the 
accuracy  of  their  planning  efforts.  TTie  following  are  suggested 
measurements  useful  in  managing  a  project: 

—  Estimated  and  actual  amount  of  project  effort  for  each  life-i^cle 
phase  and  for  each  high-level  task 

-  Estimated  and  actual  number  of  personnel  for  each  life-cycle 
phase  and  for  each  high-level  task,  including  change  in  skill  type 
required 

-  Estimated  and  actual  amount  of  other  project  costs  for  each 
life-cycle  phase  and  for  each  high-level  task 

-  Planned-to-actual  project  sdiedule  (start  and  stop  dates,  milestones) 

—  Planned-to-actual  delivery  dates  of  subcontractor  products  to 
prime 

—  Planned-to-actual  dates  of  prime  contractor  deliveries  to  the 
subcontractor 

-  Planned-to-actual  number  of  software  quality  assurance  product 
audits  and  activity  reviews  held 

•  Intermediate  and  Advanced  Maturity.  Organizations  at  intermediate  and 
advanced  levels  of  maturity  have  much  more  visibility  into  the  software 
process  at  both  the  organization  level  and  the  project  level.  In  addition 
to  the  measurements  for  organizations  at  a  low  level  of  maturity,  the 
following  are  suggested  management  measurements: 

-  Planned-to-actual  process  assessment,  development,  and 
improvement  schedule  (start  and  stop  dates,  milestones) 

-  Planned-to-actual  process  definition  schedule  (start  and  stop 
dates,  milestones) 
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-  Planned-to-actual  project  management  costs 

-  Planned-to-actual  schedule  of  the  software  engineering  group  to 
support  other  software-related  groups  (start  and  stop  dates, 
milestones) 

-  Planned-to-actual  schedule  of  the  other  software-related  groups 
to  support  the  software  engineering  group  (start  and  stop  dates, 
milestones) 
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LIST  OF  ABBREVIATIONS  AND  ACRONYMS 


APB 

Assessment  Participants  Briefing 

ATL 

Assessment  Team  Leader 

CASE 

computer-aided  software  engineering 

CMM 

Capability  Maturity  Model 

COTS 

commercial  off-the-shelf 

CSC 

computer  software  component 

CSCI 

computer  software  configuration  item 

CSU 

computer  software  unit 

FAR 

Functional  Area  Representative 

GQM 

Goal-Question-Metric 

IPT 

Integrated  Product  Ifeam 

ISO 

International  Organization  for  Standardization 

KSLOC 

thousand  source  lines  of  code 

OSP 

on-site  period 

PAT 

Process  Action  Team 

PG 

Process  Group 

PL 

Project  Leader 

QA 

quality  assurance 

QMS 

quality  management  tystems 

R&D 

research  and  development 

ROI 

return  on  investment 

SC 

Steering  Committee 

|jitefAI»biwUUoiii«nd^awiyBM 


SEI 

Software  Engineering  Institute 

SPA 

Software  Process  Assessment 

TQM 

Ibtal  Quality  Management 

UK 

United  Kingdom 

WBS 

Work  Breakdown  Structure 
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GLOSSARY 


Action  plan 


Activity 


Advocate 


i^praisal 


Assessment 


Audit 


A  |dan  that  addresses  the  steps  needed  to  be 
performed  in  order  to  im|X’ove  an  organization's 
processes.  The  following  components  are  considered 
to  be  essential:  (1)  action-oriented  description  of 
task  (for  each  action  item),  (2)  responsibility,  (3) 
resources,  and  (4)  sched^e  of  chedq)oints  and 
milestones.  An  action  plan  typically  has  three  parts: 
a  strategic  plan,  one  or  more  tactical  plans,  and  one 
or  more  operational  plans. 

A  process  step  typicalty  enacted  by  a  human,  requiring 
process  planning  and  control. 

A  person  who  promotes  process  improvement 
activities  within  the  organization.  See  also 
Champion. 

An  examination  of  an  organization's  current 
software  engineering  practices  from  a  software 
process  management  perspective.  An  important 
appraisal  goal  is  to  achieve  an  understanding  of  the 
organization's  strengths  and  weaknesses  in  key 
process  areas.  The  Software  Engineering  Institute 
has  developed  two  types  of  appraisals — ^the  Software 
Process  Assessment  and  the  Software  Capability 
Evaluation.  See  also  Software  Engineering  Institute. 

The  activities  performed  to  understand  the  current 
state  of  an  organization  as  compared  to  some 
agreed-to  metrics. 

See  Quality  audit. 


Authorizing  sponsor  An  individual  in  the  organization  who  possesses 

sufficient  authority  and  influence  to  initiate  resource 
commitment  for  major  change,  such  as  process 
improvement.  See  also  Reinforcing  sponsor. 

Capability  Maturity  Model  (CMM)  A  software  development  maturity  model,  developed 

Itythe  Department  of  Defense’s  Software  Engineer¬ 
ing  Institute,  that  provides  a  framework  to  assist  or¬ 
ganizations  in  improving  their  software  process 
(Paulk  etal.  1991). 
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Quunpion 


Change  agent 


Change  management 


Constraint 

Culture 

Customer 

Cyde 

Decision 

Environment 

Evolutionary  Spiral  Process 


Frame  of  reference 


A  person  who  publicly  supports  the  diange  effort  and 
influences  the  organization  to  obtain  commitment 
and  resources  to  implement  the  diange.  Champions 
are  usually  technical  people  who  have  earned  th. 
respect  of  the  practitioners  and  managers.  See  also 
Advocate. 

An  individual  or  group  that  is  responsible  for 
implementing  or  fadlitating  changes.  An  example  of 
a  change  agent  is  the  Process  Group.  See  Process 
Group. 

The  process  of  actively  and  explidtly  taking 
appropriate  measures  to  increase  the  likelihood  of 
effective  and  efficient  introduction  of  change  in  an 
organization.  Also,  the  body  of  knowledge  pertaining 
thereto. 

A  limitation  on  dedsion(s). 

The  values,  beliefs,  and  unwritten  rules  that  shape  an 
organization. 

The  person(s)  or  organization(s)  that  specify  the 
requirements,  accept,  and  authorize  payment  for  a 
pr^uct. 

A  cycle  is  a  complete  traversal  of  the  five  steps  of  the 
Evolutionary  Spiral  Process.  See  Evolutionary  Spiral 
Process. 

A  choice  among  allowable  alternatives. 

All  external  and  internal  conditions  that  influence 
the  form,  performance,  reliability,  or  survival  of  an 
organization  (adapted  from  MIL-STD-721C). 

Any  enactment  of  the  evolutionary  spiral  model, 
which  is  an  adaptation  of  the  basic  spiral  model  pro¬ 
posed  by  Barry  Boehm  (1986;  1988),  that  emphasizes 
the  evolutionary  development  of  systems. 

The  point  of  view  of  an  individual  stakeholder  or 
stakeholder  group.  The  organization’s  frame  of 
reference  is  its  culture. 
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Functional  areas 

Goal 

Historical  data 
Influence  strategy 

Institutionalization 

ISO  9000 

Life  cycle 

Maturity 

Measurement 

Method 

Methodology 

Metric 

Mitigation 

Model 


Tbchnical  stages,  phases  or  unit  operations  of  the 
software  process.  For  a  typical  assessment,  these  are 
software  quality  assurance  and  release,  software 
integration  and  test,  coding  and  unit  test,  detailed 
design,  requirements,  and  high-level  design. 

A  specific,  time-related,  measurable  target. 

An  accumulated  database  of  metrics,  plans,  and 
experience  from  previous  projects. 

A  formal  or  informal,  written  or  unwritten  strategy 
for  gaining  buy-in  from  appropriate  management 
and  staff  on  process  improvement  and  its 
implementation  within  the  organization. 

Represents  the  activities  undertaken  by  an 
organization  to  make  a  process  a  routine  and  necessary 
part  of  the  organization’s  work  environment 

A  family  of  standards  covering  the  requirements  for 
quality  management  systems  for  manufactured 
products  and  services. 

A  sequence  of  distinct  states  of  an  entity  beginning 
with  its  initial  conception  and  ending  when  it  is  no 
longer  available  for  use. 

See  Process  maturity. 

A  number  assigned  to  a  directly  observable  aspect  of 
a  process  or  product. 

Guidance  and  criteria  that  prescribe  a  systematic, 
repeatable  technique  for  performing  an  activity. 

An  integrated  body  of  principles,  practices,  and 
methods  that  prescribe  the  proper  performance  of  a 
process. 

A  function  of  one  or  more  measurements.  A  metric 
may  be  directly  observable  or  may  be  derived 
through  a  calculation  involving  one  or  more  metrics 
and  measurements. 

See  Risk  mitigation. 

A  representation  of  a  thing  from  analysis 

provides  approximate  answers  to  designated  questions 
about  the  thing  itself. 
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Objective 
Operational  plan 

Organization 

Plan 

Process 


Process  action  team  (PAT) 


Process  asset 


Process  group  (PG) 


Process  improvement  process 


Process  maturity 


Process  user 


The  intended  or  desired  result  of  a  course  of  actkuL 

A  plan  that  describes  the  activities  performed  to 
transfer  a  particular  tedmology  from  a  PAT  to  a 
project. 

Usually  the  portion  of  an  enterprise  bounded  by  the 
span  of  authority  of  the  senior  site  executive. 

A  designation  of  tasks  and  resource  allocations  for 
accomplishing  a  specified  objective. 

(1)  A  (partially)  ordered  set  of  steps,  intended  to 
accomplish  specified  objective(s);  (2)  the  l<^cal 
organization  of  people,  madiines,  tools,  methods, 
and  procedures  into  work  activities  designed  to 
produce  a  specified  end  result  (work  product).  The 
term  software  process  refers  to  processes  that  are 
intrinsic  to  developing  and  evolving  software 
^tems.  See  also  Sof^are  process. 

A  group  that  is  responsible  for  developing  and 
implementing  a  plan  to  improve  a  spedfic  area  of  the 
process. 

Documentation  or  work  product  (e.g.,  report, 
policies  and  procedures)  developed  during  the 
process  improvement  process. 

A  group  that  is  responsible  for  maintaining  and 
improving  the  process  standards,  policies,  and 
procedures,  as  well  as  refining  any  process  models 
and  historical  data. 

The  process,  as  defined  in  this  guidebook,  by  whidi 
an  organization  improves  its  processes.  It  includes 
the  following  steps:  Understand  Context,  Analyze 
Risks  and  Select  Strategy,  Plan  Improvements, 
Implement  Improvements,  and  Review  and  Update. 

The  extent  to  which  the  software-specific  processes 
used  by  a  software  organization  are  explicitly 
defined,  managed,  measured,  and  controlled. 

An  individual  who  performs  a  process.  In  process 
improvement,  this  individual  is  expected  to  change 
the  way  work  is  performed  by  using  the  improved 
process. 
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Product 

Froigram 

Project 

Project  manager 

Quality  audit 

Readiness  to  change 
Reinforcing  sponsor 

Resources 

Risk 

Risk  analysis 
Risk  management 

Risk  mitigation 

Role 


The  aggregation  of  all  work  [voducts  resulting  from 
a  process  or  activity. 

A  directed*  funded  effort  to  acquire,  develop,  or 
maintain  a  ivoduct(s). 

An  undertaking  requiring  concerted  effort,  t^liicfa  is 
focused  on  develo|^  and/or  maintaining  a  specific 
product,  'typically  a  project  has  its  own  fundii^  cost 
accounting,  and  delivery  sdiedule. 

A  person  responsible  for  the  management  of  a 
project.  Also,  a  person  directly  responsible  for  the 
definition,  cost,  and  sdiedule  of  a  [X’oduct 

As  used  by  ISO  9000,  a  systematic  and  independoit 
examination  to  determine  Aether  quality  activities 
and  related  results  oom]^  with  i^ann^  arrangements 
and  viliether  these  arrangements  are  imjdemented 
effectively  and  are  suitable  to  adiieve  objectives. 

An  organization’s  receptiveness  to  and  ability  to 
change. 

An  individual  in  the  organization  uiio  possesses 
sufRdent  authority  and  influence  to  reinforce  change 
efforts,  such  as  process  improvement  activities.  See 
also  Authorizing  sponsor. 

People,  time,  and  money. 

A  potential  for  incurring  undesirable  results. 

The  act  of  identifying,  estimating,  and  evaluating  risk 
to  determine  whether  risk  mitigation  is  necessary. 

A  management  approach  focused  on  identifying, 
addressing,  and  removing  risk  items  before  they  be¬ 
come  either  threats  to  successful  product  operation 
or  major  sources  of  rework. 

Action  taken  to  reduce  a  risk  to  an  acceptable  level 
by  working  to  change  the  probability  of  a  risk 
occurring  or  the  cost  of  a  risk  occurring. 

A  function  within  the  process  improvement  process. 


Software  Engineering  Institute  (SEI)  A  federally  funded  research  and  development  center 

sponsored  by  the  Department  of  Defense  and 
managed  by  Carnegie  Mellon  University. 
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Software  engineering  tedinology 

Software  process 

Software  process  management 

Spiral 

Sponsor 

Stakeholder 

Steering  Committee  (SC) 

Step 

Strategic  plan 
^tem 
Ihcdcal  plan 
Ihsk 


Ibdmology  whose  purpose  and  function  is  to  support 
the  engineering,  development,  operaticm,  and/or 
maintenance  of  a  software-based  system. 

A  process  performed  to  (a’oduce,  support,  maintain, 
and  enhance  software.  Examples  of  a  software 
process  are  a  software  develojHnent  fvocess  and  a 
software  maintenance  i^ocess. 

The  use  of  process  engineering  concepts,  tediniques, 
and  practices  to  ocplidtly  monitor,  control,  and  im¬ 
prove  the  software  fM^ocess.  The  objective  of  software 
process  management  is  to  enable  an  organization  to 
produce  software  products  according  to  plan,  while 
simultaneously  improving  its  ability  to  produce 
better  products. 

One  or  more  cycles  that,  when  combined,  accomi^ish 
a  specific  objective. 

An  individual  in  the  organization  wdio  su|:^rts 
process  improvement  activities  within  the 
organization  through  the  allocation  of  people,  time, 
and  money.  See  also  Authorizing  sponsor  and 
Reinforcing  sponsor. 

A  person  or  group  with  a  personal  or  business  interest 
in  the  siKxess  or  failure  of  process  improvements. 

The  organization  that  sets  priorities  for  process 
improvement  initiatives  and  recommends  to  the 
sponsor  the  authorization  of  all  actions  undertaken 
by  the  Process  Group. 

Either  an  activity  or  an  unelaborated  action. 

A  plan  that  describes  the  motivation  and  direction  of 
the  organization’s  process  improvement  program. 

A  collection  of  hardware,  software,  and  people  that 
operate  together  to  accomplish  a  mission. 

A  plan  that  describes  the  activities  performed  during 
each  tycle. 

A  work  assignment  (i.e.,  subject  to  management 
accountability)  to  accomplish  a  specified  objective. 
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Ibchnology 

Ifcchnology  transfer 

Ibchnolt^  transition 
User 

Validation 

Vendor 
Work  product 


Ibcfaniques,  tools,  or  laxM^edge  that  aids  in 
accomi^shing  some  task  (adapted  frtnn  Williams 
and  Gibson  1990;  Software  ProducdviQr  Ccmsortium 
1988). 

The  process  by  which  a  technolt^  goes  frcnn 
develofmient  by  a  tedinology  producer  to  use  by  a 
technology  consumer.  This  term  is  sometimes 
referred  to  as  tedinology  transition. 

See  Ibdinology  tranter. 

The  person(s)  or  organization(s)  that  will  use  the 
system  for  its  intended  purpose  when  it  is  de[doyed 
in  its  environment. 

The  evaluation  of  work  products  to  determine 
whether  th^  satisfy  customer  needs. 

A  supf^er  of  commerdal  off-the-shelf  (CX)TS)  tools 
or  software  to  be  used  to  develop  the  [voduct 

Any  configuration-managed  artifact  that  is  the 
embodiment  of  some  data  element(s). 
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tactical  i^n,  6-4, 6-6 
Strategic  Plan,  4-14 
Strategic  Planning,  9-3-9-4 
Subcontractors,  9-10 


Supi^rs,  9-10 
Si^q^wrt,  9-6 

of  the  Process  Action  Team,  7-8 


Ibchnical  Support.  See  Support 
'Ibdinology  Purees,  9-10 
Ibchnology  Transfer,  Process  Improvement,  1-6 
lbdinol<^  Ihmsfer  Process,  1-6, 9-7 
Tbtal  Quality  Management  (TQM),  2-3, 4-17, 9-3, 
9-4 

llaining,  7-9, 9-4, 9-5 

IVansition  Model.  See  Change  Model,  three-stage 
Transition  stage,  7-11 
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